Reduce tansaction size: by including compressed EC point

[SmartLayer]

I found that a devcon ticket is 92 bytes and a signedDevconTicket is as big as 396 bytes, which will bloat the bockchain. I'm thinking if there are ways to reduce it, since bytes costs on Ethereum too.

First, we can reduce devcon ticket by using compressed EC point (byte 17)

$ openssl asn1parse -inform DER < build/test-results/signed-devcon-ticket.der
    0:d=0  hl=4 l= 392 cons: SEQUENCE          
    4:d=1  hl=2 l=  78 cons: SEQUENCE          
    6:d=2  hl=2 l=   1 prim: INTEGER           :06
    9:d=2  hl=2 l=   3 prim: INTEGER           :BE06
   14:d=2  hl=2 l=   1 prim: INTEGER           :00
   17:d=2  hl=2 l=  65 prim: OCTET STRING      [HEX DUMP]:040AFDF0E2474CAE9B6616F04BACDD9F76AB5882DBB8399D3F60A15361DAD7030F27BE3F583FE45DE9495F84F48237EC2B7C710EB3B5D2E7A5652D8D56C718256F
   84:d=1  hl=3 l= 236 cons: SEQUENCE          
   87:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   96:d=2  hl=3 l= 224 cons: SEQUENCE          
   99:d=3  hl=2 l=   1 prim: INTEGER           :01
  102:d=3  hl=2 l=  44 cons: SEQUENCE          
  104:d=4  hl=2 l=   7 prim: OBJECT            :prime-field
  113:d=4  hl=2 l=  33 prim: INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
  148:d=3  hl=2 l=  68 cons: SEQUENCE          
  150:d=4  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:0000000000000000000000000000000000000000000000000000000000000000
  184:d=4  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:0000000000000000000000000000000000000000000000000000000000000007
  218:d=3  hl=2 l=  65 prim: OCTET STRING      [HEX DUMP]:0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
  285:d=3  hl=2 l=  33 prim: INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
  320:d=3  hl=2 l=   1 prim: INTEGER           :01
  323:d=1  hl=2 l=  71 prim: BIT STRING        

Furthermore, we can reduce hugely by the use of compressed points

Proof ::= SEQUENCE {
    base                 OCTET STRING,
    riddle               OCTET STRING,
    challengePoint       OCTET STRING,
    responseValue        OCTET STRING
}

[jot2re]

For completeness I will just mention that we discussed this issue at the meeting and after consulting with @JamesSmartCell we came to the conclusion that it would probably end up being more expensive to use a compressed point, since then the y point must be recomputed. However, this can be further investigated. Maybe when @JamesSmartCell has time to write two Solidity tests; one that uses the full point and one that computes it from a compressed point.