1 2017-12-29 04:53:25 <DSidH> arubi: a quick question about ECC. Can I throw and error when point at infinity is encountered?
 2 2017-12-29 04:53:48 <DSidH> are there any situations where computing point at infinity is legit in bitcoin?
 3 2017-12-29 04:56:52 <eck> no
 4 2017-12-29 04:56:55 <eck> certain pk values are disallowed
 5 2017-12-29 04:57:00 <eck> e.g. 0
 6 2017-12-29 05:02:31 <DSidH> eck what about verifying signatures? will we ever encounter it then?
 7 2017-12-29 05:03:40 <eck> you can create a tx that sends coins to an invalid address, in which case the coins either become anyone-can-spend or no-one-can-spend depending on the exact situation
 8 2017-12-29 05:07:43 <eck> i believe though (someone correct me if i am wrong) that signature verification just requires add/multiply operations, so there are no pathological values from that pov
 9 2017-12-29 05:09:59 <eck> and modulus, i guess
10 2017-12-29 05:10:08 <eck> https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_verification_algorithm
11 2017-12-29 05:12:58 <rmt> FTR, https://bitcoin.stackexchange.com/questions/61907/uxto-db-structure answers my question above.
12 2017-12-29 05:14:37 <eck> here's where this could come up though, as you can see from the wikipedia article, in a normal ECDSA signature you do a sanity check of the public key, e.g. check that it is within the expected range
13 2017-12-29 05:15:04 <eck> most transactions in the bitcoin network are P2PKH, meaning that the tx script contains the hash of the public key rather than the full public key itself
14 2017-12-29 05:15:30 <eck> therefore other nodes can't properly validate the public key used, since they only know the hash, not the full public key
15 2017-12-29 05:15:52 <eck> so you could create an invalid public key, and then if you used it in a P2PKH transaction it would be "unspendable"
16 2017-12-29 05:16:58 <eck> more technically, from a mathematical pov there is likely some valid public key that has the same hash (as the hash is only 160 bits, vs 256 for the full key), but in practice it becomes unspendable since no one knows what that valid key is
17 2017-12-29 05:19:19 <DSidH> eck Invalid keys can be handled. I am more worried about legit keys because sig validation requires aX + bY for two good points X and Y
18 2017-12-29 05:19:57 <DSidH> if aA = -bY this could lead to point at infinity
19 2017-12-29 05:20:07 <DSidH> (aX = -bY)
20 2017-12-29 05:21:14 <DSidH> and attacker could construct other values that cause this
21 2017-12-29 05:21:21 <eck> example?
22 2017-12-29 05:21:36 <DSidH> not sure, just a worry
23 2017-12-29 05:21:57 <eck> i don't think that would leat to a point at infinity
24 2017-12-29 05:22:06 <eck> that would lead to a point at zero which is not allowed anyway
25 2017-12-29 05:23:07 <DSidH> how does core handle this?
26 2017-12-29 05:23:42 <eck> i can't tell you off hand but my assumption is it would be unspendable for the reason i just gave
27 2017-12-29 05:24:14 <DSidH> yup thats cool as long as I am following the same rules
28 2017-12-29 05:26:20 <DSidH> I wanted to keep (0, 0) as a special case for point at infinity as others have done but that feels hacky
29 2017-12-29 05:26:54 <DSidH> tacky*
30 2017-12-29 05:27:34 <eck> well the issue is if you used 0 as your private key, the multiplication privkey * G would trivially be zero also
31 2017-12-29 05:27:51 <eck> which is why 0 is disallowed
32 2017-12-29 05:28:29 <eck> i don't know how this works with ancient p2pk txs though
33 2017-12-29 05:29:34 <DSidH> eck for instance in key recovery we need to test that nR is point at infinity; currently I am doing it via exception. This is the only case I have encountered it
34 2017-12-29 05:30:55 <DSidH> btw ignore the actual notation as I dont remember the formula but we need to test that aX is infinite for some a, X
35 2017-12-29 05:31:14 <eck> if you're using libsecp256k1 it should handle the edge cases for you, if you have your own implementation i would suggest trying to port the libsecp256k1 tests to your implementation
36 2017-12-29 05:36:43 <DSidH> https://eprint.iacr.org/2015/1060.pdf Has anyone looked at this? (complete formula for ECC addition without exceptions)
37 2017-12-29 06:40:56 <blyat_> Is there any documentation for the debug categories?
38 2017-12-29 07:23:15 <arubi> DSidH, I'm actually not sure what's the safe and correct way to handle that.  I'm returning "not a point" for both non points and the point at infinity, but it only means "error" depending on what the program is doing.  for example in signature validation \ pubkey recovery, the r value is allowed to be an invalid x coordinate in some cases, like in the rec_r_big file I posted on gist.  the sec1-v2 doc says when you should be failing and when
39 2017-12-29 07:23:16 <arubi> to try again with different values
40 2017-12-29 07:57:38 <arubi> but yea since I can just feed you signatures where ( s = z/k ), there should be a safe way to handle that..  I'm failing with "Runtime error (func=invmod, adr=37): Divide by zero" which is not very nice :)
41 2017-12-29 08:07:05 <xiedeacc> what's CCoinsViewDB::GetHeadBlocks for? I have google a lot, there exists little information
42 2017-12-29 08:19:46 <xiedeacc> what's CCoinsViewDB::GetHeadBlocks for? I have google a lot, there exists little information
43 2017-12-29 09:26:49 <DSidH> EXIT
44 2017-12-29 11:20:04 <firemanxbr> inb
45 2017-12-29 15:25:24 <camarads> hey guys. can anybody tell me when will the new bitcoin core be available ? i have been waiting for the change address to be segwit also
46 2017-12-29 15:55:09 <molz> camarads, when it's ready
47 2017-12-29 15:55:30 <molz> i'm waiting for v0.16.0 too, that's the version that has native segwit in the wallet
48 2017-12-29 15:57:23 <camarads> it would be perfect for the rpc api to have that option
49 2017-12-29 15:57:41 <camarads> when i use sendtoaddress , the change address to be segwit
50 2017-12-29 19:14:37 <qwertzlcoatl> yo my bitcoin core app keeps crashing when i try to load it? it verifies blocks than says "loading finished" but then it just crashes? anyone ?
51 2017-12-29 19:21:00 <molz> qwertzlcoatl, which version and which OS?
52 2017-12-29 19:21:17 <qwertzlcoatl> hold up this time it worked
53 2017-12-29 23:13:42 <G0pn1k> o/
54 2017-12-29 23:13:45 <G0pn1k> hi all
55 2017-12-29 23:15:42 <Randolf> Hello G0pn1k.
56 2017-12-29 23:18:46 <G0pn1k> i was wondering if someone could maybe point me in the right direction, i might be being an idiot but im trying to query core to see basically an address has ever recieved funds
57 2017-12-29 23:19:34 <G0pn1k> i figured i would have to do something like txindex=1 and build a db of public keys that have ever existed in a transaction maybe? but im not too sure
58 2017-12-29 23:20:01 <echeveria> you don't need txindex for that, but you'll be doing something external.
59 2017-12-29 23:20:19 <G0pn1k> i want to avoid any apis and such, maybe i should have said
60 2017-12-29 23:20:26 <G0pn1k> unless i understand external wrong
61 2017-12-29 23:20:28 <echeveria> take a look at something like bitcoin-iterate.
62 2017-12-29 23:22:15 <G0pn1k> ah ok, so itterate over each hash and look at the from and to?
63 2017-12-29 23:23:13 <echeveria> it's the name of a tool. there's no 'from' in bitcoin.
64 2017-12-29 23:24:04 <G0pn1k> sorry, still trying to get my head around a lot it
65 2017-12-29 23:25:03 <G0pn1k> i thought if i itterate each transaction that is output from that script i could look at the resultant address and build a db from them all