a special public key can't be in key_auths array: Missing Active Authority about bitsharesjs HOT 15 CLOSED

I think I've got an fix and also a workaround. I don't know how to make pull request but here's the git diff. Just a small line change in types.js.

diff --git a/lib/serializer/src/types.js b/lib/serializer/src/types.js
index f2d5f40..8109420 100644
--- a/lib/serializer/src/types.js
+++ b/lib/serializer/src/types.js
@@ -792,7 +792,7 @@ Types.public_key = {
         return object.toString()
     },
     compare(a, b) {
-        return strCmp(a.toAddressString(), b.toAddressString())
+        return a.toBlockchainAddress().compare(b.toBlockchainAddress())
     }
 };

The workaround is also to make change to types.public_key.compare before serialization:

const {types} = require("bitsharesjs");
types.public_key.compare = (a,b)=>a.toBlockchainAddress().compare(b.toBlockchainAddress());

from bitsharesjs.

to reproduce, put the pub key in any light wallet , click save.

from bitsharesjs.

Ok this is very interesting. @abitmore what is the expected result of the serialization? If I have that I can write a unit test and figure out what's wrong in the js serialization.

from bitsharesjs.

here I paste an error report with serialization hash which has been checked by @abitmore yesterday:

Error: missing required active authority: Missing Active Authority 1.2.444731bitshares-crypto digest 5f8387870251d9c7cef8fed84066506c0a7133bad2c0ffd8abcf0033d9239a05 transaction 8fc336d8d65b6d1a215a0106bd0400000000000000bb921b010300000002d2d60901009ff91a01000203b666ae35954e2b7b3e5e3430f49b0a971b3e8f13cfb3240055205f758abfd625010002def83f652f3d47a2f96b97928779bcc7155db4c1fa7570f60e3af07647777da60100000102000000029ff91a0100eb8f1d010001020f08edaefcacd7dd29ffb51b4b3b20fe1f5c0946b4e11fd499c093a5234201d0010000000000 {"ref_block_num":50063,"ref_block_prefix":1540806710,"expiration":"2017-12-01T09:01:33","operations":[[6,{"fee":{"amount":"1213","asset_id":"1.3.0"},"account":"1.2.444731","owner":{"weight_threshold":3,"account_auths":[["1.2.158546",1],["1.2.441503",1]],"key_auths":[["BTS8DZinV1rFkdgs2sMMhUrk6wAyq1fTB8eLKQzcYihkgrjiv3tLn",1],["BTS6agpGeRkc1zHD9MTbHaK9CKR1Pt8aU4v2GTxF6tRtf3ZC3TnU6",1]],"address_auths":[]},"active":{"weight_threshold":2,"account_auths":[["1.2.441503",1],["1.2.477163",1]],"key_auths":[["BTS517Q7o3TgYnsaduUwLRUekPdHzu1cgx9LtskoRJghJ8yeo19eR",1]],"address_auths":[]},"extensions":[]}]],"extensions":[],"signatures":["1f0ba592086930dd6e7594abdc08054157013da744b3f0c6810e8b46606a3d0b19510cdc5096b7aab96dfa6aa30631c2380c71322c135e80b7c7f87e5615dc0103","202e1879157c9f621ca3dc0c3e4c079f91609735962eb444015f3500a20d7da8a1706f2fa420858d24fac75348617daca027f84871a6b85cf2ac7e84a3eff135e9"]}

and another one with owner and active sig:

Error: missing required active authority: Missing Active Authority 1.2.444731bitshares-crypto digest 2d80adc2b10f60b545a9b40ba2ab54657bde82ecf963dff85fa715d8c15a83e8 transaction c0c297c3729df517215a0106bd0400000000000000bb921b010300000002d2d60901009ff91a01000203b666ae35954e2b7b3e5e3430f49b0a971b3e8f13cfb3240055205f758abfd625010002def83f652f3d47a2f96b97928779bcc7155db4c1fa7570f60e3af07647777da60100000102000000029ff91a0100eb8f1d010001020f08edaefcacd7dd29ffb51b4b3b20fe1f5c0946b4e11fd499c093a5234201d0010000000000 {"ref_block_num":49856,"ref_block_prefix":2641544087,"expiration":"2017-12-01T08:51:01","operations":[[6,{"fee":{"amount":"1213","asset_id":"1.3.0"},"account":"1.2.444731","owner":{"weight_threshold":3,"account_auths":[["1.2.158546",1],["1.2.441503",1]],"key_auths":[["BTS8DZinV1rFkdgs2sMMhUrk6wAyq1fTB8eLKQzcYihkgrjiv3tLn",1],["BTS6agpGeRkc1zHD9MTbHaK9CKR1Pt8aU4v2GTxF6tRtf3ZC3TnU6",1]],"address_auths":[]},"active":{"weight_threshold":2,"account_auths":[["1.2.441503",1],["1.2.477163",1]],"key_auths":[["BTS517Q7o3TgYnsaduUwLRUekPdHzu1cgx9LtskoRJghJ8yeo19eR",1]],"address_auths":[]},"extensions":[]}]],"extensions":[],"signatures":["1f27b16f6ec97a615383e05bad80e4c9c2015c36a472dd9ec15597f9f2a15d765d330eff51e06e2fed6c7276e5e708c7782b46d2ff80e4eb17bcf19086c0220dea"]}

from bitsharesjs.

Serialization results got from backend:

$ curl -d '{"id":1,"method":"call","params":[0,"get_transaction_hex",[{"ref_block_num":50063,"ref_block_prefix":1540806710,"expiration":"2017-12-01T09:01:33","operations":[[6,{"fee":{"amount":"1213","asset_id":"1.3.0"},"account":"1.2.444731","owner":{"weight_threshold":3,"account_auths":[["1.2.158546",1],["1.2.441503",1]],"key_auths":[["BTS8DZinV1rFkdgs2sMMhUrk6wAyq1fTB8eLKQzcYihkgrjiv3tLn",1],["BTS6agpGeRkc1zHD9MTbHaK9CKR1Pt8aU4v2GTxF6tRtf3ZC3TnU6",1]],"address_auths":[]},"active":{"weight_threshold":2,"account_auths":[["1.2.441503",1],["1.2.477163",1]],"key_auths":[["BTS517Q7o3TgYnsaduUwLRUekPdHzu1cgx9LtskoRJghJ8yeo19eR",1]],"address_auths":[]},"extensions":[]}]],"extensions":[],"signatures":["1f0ba592086930dd6e7594abdc08054157013da744b3f0c6810e8b46606a3d0b19510cdc5096b7aab96dfa6aa30631c2380c71322c135e80b7c7f87e5615dc0103","202e1879157c9f621ca3dc0c3e4c079f91609735962eb444015f3500a20d7da8a1706f2fa420858d24fac75348617daca027f84871a6b85cf2ac7e84a3eff135e9"]}]]}' http://127.0.0.1:28080/ws

{"id":1,"jsonrpc":"2.0","result":"8fc336d8d65b6d1a215a0106bd0400000000000000bb921b010300000002d2d60901009ff91a01000202def83f652f3d47a2f96b97928779bcc7155db4c1fa7570f60e3af07647777da6010003b666ae35954e2b7b3e5e3430f49b0a971b3e8f13cfb3240055205f758abfd6250100000102000000029ff91a0100eb8f1d010001020f08edaefcacd7dd29ffb51b4b3b20fe1f5c0946b4e11fd499c093a5234201d0010000000000021f0ba592086930dd6e7594abdc08054157013da744b3f0c6810e8b46606a3d0b19510cdc5096b7aab96dfa6aa30631c2380c71322c135e80b7c7f87e5615dc0103202e1879157c9f621ca3dc0c3e4c079f91609735962eb444015f3500a20d7da8a1706f2fa420858d24fac75348617daca027f84871a6b85cf2ac7e84a3eff135e9"}

$ curl -d '{"id":1,"method":"call","params":[0,"get_transaction_hex",[{"ref_block_num":49856,"ref_block_prefix":2641544087,"expiration":"2017-12-01T08:51:01","operations":[[6,{"fee":{"amount":"1213","asset_id":"1.3.0"},"account":"1.2.444731","owner":{"weight_threshold":3,"account_auths":[["1.2.158546",1],["1.2.441503",1]],"key_auths":[["BTS8DZinV1rFkdgs2sMMhUrk6wAyq1fTB8eLKQzcYihkgrjiv3tLn",1],["BTS6agpGeRkc1zHD9MTbHaK9CKR1Pt8aU4v2GTxF6tRtf3ZC3TnU6",1]],"address_auths":[]},"active":{"weight_threshold":2,"account_auths":[["1.2.441503",1],["1.2.477163",1]],"key_auths":[["BTS517Q7o3TgYnsaduUwLRUekPdHzu1cgx9LtskoRJghJ8yeo19eR",1]],"address_auths":[]},"extensions":[]}]],"extensions":[],"signatures":["1f27b16f6ec97a615383e05bad80e4c9c2015c36a472dd9ec15597f9f2a15d765d330eff51e06e2fed6c7276e5e708c7782b46d2ff80e4eb17bcf19086c0220dea"]}]]}' http://127.0.0.1:28080/ws

{"id":1,"jsonrpc":"2.0","result":"c0c297c3729df517215a0106bd0400000000000000bb921b010300000002d2d60901009ff91a01000202def83f652f3d47a2f96b97928779bcc7155db4c1fa7570f60e3af07647777da6010003b666ae35954e2b7b3e5e3430f49b0a971b3e8f13cfb3240055205f758abfd6250100000102000000029ff91a0100eb8f1d010001020f08edaefcacd7dd29ffb51b4b3b20fe1f5c0946b4e11fd499c093a5234201d0010000000000011f27b16f6ec97a615383e05bad80e4c9c2015c36a472dd9ec15597f9f2a15d765d330eff51e06e2fed6c7276e5e708c7782b46d2ff80e4eb17bcf19086c0220dea"}

from bitsharesjs.

I think this is a public_key sorting issue which we've encountered in year 2015. I will link that issue here soon.

from bitsharesjs.

Related issues in the past:
cryptonomex/graphene-ui#795
cryptonomex/graphene#630

from bitsharesjs.

Another case:
bitshares/bitshares-core#607
https://bitsharestalk.org/index.php/topic,25889.0.html

from bitsharesjs.

I guess the problem happens on transaction.cpp :307 and the result public key recovered from signature is wrong for some reason. Hope this can help.
You can check my issue bitshares/bitshares-core#607 where you can see a strange public key in sigs. From the code, sigs is a list const of public keys recovered from signature.
result.insert( fc::ecc::public_key(sig,d) ).

from bitsharesjs.

@zhangweis because the transaction serialization done by js is incompatible with cpp, so when the node is checking the signature, it got another key. I think it's easier to be fixed from js side, even if there is a bug in core.

from bitsharesjs.

@abitmore Thanks for the explanation.
[BTS6JicNdetyZf2kceu86Ms47iLNshty1rthKtnL7fSej7DtKyJNu,BTS7i8ePNeLCAxcWjaEeqsDFRZdSeMoF4gZmfe54EqrdX4AdQMY3k] can be another failure case for reference.
I tried swapping them but with no luck. Both [BTS6JicNdetyZf2kceu86Ms47iLNshty1rthKtnL7fSej7DtKyJNu,BTS7i8ePNeLCAxcWjaEeqsDFRZdSeMoF4gZmfe54EqrdX4AdQMY3k] and [BTS7i8ePNeLCAxcWjaEeqsDFRZdSeMoF4gZmfe54EqrdX4AdQMY3k, BTS6JicNdetyZf2kceu86Ms47iLNshty1rthKtnL7fSej7DtKyJNu] have been tried.
tr_buffer:abcfb004edcebf13715a010621000000000000007188cd290101000000000202bab5c458f5a10cf4ff5573de6c07b276c51bf48ae21b37f6b38dce80e97371c3010003739244d3500d992386975496f722b946007e9843c4b678fa3887390fb5ee0a6d0100000101000000000202bab5c458f5a10cf4ff5573de6c07b276c51bf48ae21b37f6b38dce80e97371c3010003739244d3500d992386975496f722b946007e9843c4b678fa3887390fb5ee0a6d010000000000
sig:205620505065e578beb668c09a6ea7f04e8b12bb4f6cf86c9b6a6a82356506a3963527ee930d606a003597d172bd76cb89d1d95bbdf20ed2293324f54160353392
another:
d3cf658ae5833914715a010621000000000000007188cd290101000000000202bab5c458f5a10cf4ff5573de6c07b276c51bf48ae21b37f6b38dce80e97371c3010003739244d3500d992386975496f722b946007e9843c4b678fa3887390fb5ee0a6d0100000101000000000202bab5c458f5a10cf4ff5573de6c07b276c51bf48ae21b37f6b38dce80e97371c3010003739244d3500d992386975496f722b946007e9843c4b678fa3887390fb5ee0a6d010000000000
sig:205ba6c595d7b54bf305373d1f683f62d0534947caaa9d27da8b70677f9fc8f34e5f6fd6cdc89d6db512f67cfe3506273ff8eff802ab29e412285485b10cefd6d1

from bitsharesjs.

I'm curious why there is a difference. Perhaps something went wrong when converted to string, for example, due to leading zeroes?

    toBlockchainAddress() {
        var pub_buf = this.toBuffer();
        var pub_sha = sha512(pub_buf);
        return ripemd160(pub_sha);
    }
    toAddressString(address_prefix = ChainConfig.address_prefix) {
        var pub_buf = this.toBuffer();
        var pub_sha = sha512(pub_buf);
        var addy = ripemd160(pub_sha);
        var checksum = ripemd160(addy);
        addy = Buffer.concat([addy, checksum.slice(0, 4)]);
        return address_prefix + encode(addy);
    }

So, toAddressString() is buggy? If yes, it may need a fix.

@pluswave @svk31 please check.

from bitsharesjs.

@abitmore I guess the issue is that the encoded base58 strings have different length. It's like 5 should be less that 12 but if you use string compare, you'll get "5" > "12".
In your case address string (Base58) of BTS8DZinV1rFkdgs2sMMhUrk6wAyq1fTB8eLKQzcYihkgrjiv3tLn(3840abd1738e465ae01552e54eb5846b3d047096) is 68SKB5gBwJNihnmea2WdQ2RkXZtybc5r1(length:33) and BTS6agpGeRkc1zHD9MTbHaK9CKR1Pt8aU4v2GTxF6tRtf3ZC3TnU6(081cd8e317b8eccb5a7abfe9d7372910d6906ed3) is jtxsi7g7BkE45PexXoe5VjiV1HnXeToK(length:32).

from bitsharesjs.

@zhangweis looks like the leading zero (the first 0 in the second key 08...) got removed when encoding to Base58 address string. I guess it's legit to do so, however, can't compare strings directly. Thanks.

from bitsharesjs.

@pluswave can you help check if @zhangweis's patch works? If yes, make a PR for this? Thanks.

from bitsharesjs.