Invalid ring signatures on non-XMR coin

[valiant1x]

Hello,

I attempted to use your pool for a new CryptoNote fork. It worked great for unlocking and hashing blocks, and hashed over 75 blocks without complaint - but it is sending bad transactions that complain of invalid ring signatures in the daemon. Payments process without error in the pool itself.

(payments_info.log)

2017-08-17 01:58:09 Payments sent via wallet daemon {"tx_hash":"a602f446b84ac4e4ab46e8c2303bfe09b0d41362d786ad102d3dde08588a1105"}

Therefore the pool is unusable and all payouts unsent. I also saw a daemon complaint about an invalid unlock time specified in a txn, although I did correctly set the config.blockUnlocker.depth value.

Looking at the code in lib/paymentProcessor.js, it looks like it simply sends queries to the simplewallet RPC, so I'm not sure why it's creating invalid ring signatures. Are there specific portions of the cryptonote-util branch that encode for coin specific vars?

Is there any logging in place to reveal the exact RPC data going to the wallet to send payments?

Thanks so much.

[clintar]

Probably because of the xmr changes. Maybe try this branch I just created that I think worked with monero before they went to ringct. https://github.com/clintar/node-cryptonote-util/tree/forknote_comp
You can just change the package.json to have
"cryptonote-util": "git://github.com/clintar/node-cryptonote-util.git#forknote_comp"
then remove the node_modules folder and run npm update again. Let me know if it works.

[valiant1x]

When I initially tried your suggestion, I saw the same issue - invalid ring signature.

I tried reverting to a cryptonote-utils branch in zone117x's fork, since that one worked at one time, and was STILL seeing the same error. I tried a sanity check curl 127.0.0.1:port wallet payment, and saw the same error. Huh?

I re-synced the daemon blockchain and reset simplewallet, and now all is well! It seems it was all a wallet or daemon error the whole time. Somehow the data got corrupted is my best guess. However, I AM now using your forknote_comp branch. I'm not sure if that fixed things. I'm hesitant to try reverting to your original cryptonote-util branch to find out. It's possible the original branch somehow broke or corrupted the blockchain or wallet.

For now, I think we can consider this solved. Thanks so much.

[valiant1x]

Issues persisted until the coin core was updated to Bytecoin v2.1. Problems are now resolved. It would seem that the cryptonote foundation fork has issues over time with block sizes, likely related to memory corruption due to the nondeterministic and sporadic nature of the issue. Historic problem text below to help others that may experience this issue in the future.

I may have spoken too soon! It ran great for about 500 blocks. Now, while the pool has continued mining up to block 1560, remote daemons are stuck at block 1510ish and complain of the following:

09:05:31.131608 INFO SYNCHRONIZATION started
09:05:31.357296 INFO Wrong index in transaction inputs: 432, expected maximum 430
09:05:31.357477 INFO Failed to get output keys for tx with amount = 20.00000000 and count indexes 1
09:05:31.357581 INFO Failed to check ring signature for tx <1d3a9cfb8498a2e2adb2837f81953b1057815d1baa245a00dd0aa4340c1fb73e>
09:05:31.789071 INFO Wrong index in transaction inputs: 432, expected maximum 430
09:05:31.789218 INFO Failed to get output keys for tx with amount = 20.00000000 and count indexes 1
09:05:31.789332 INFO Failed to check ring signature for tx <1d3a9cfb8498a2e2adb2837f81953b1057815d1baa245a00dd0aa4340c1fb73e>
09:05:31.789396 INFO Block <1eca1e0bf5f71f03c50551192294a350e996ce974fc500d908940048d9514d2b> has at least one transaction with wrong inputs: <1d3a9cfb8498a2e2adb2837f81953b1057815d1baa245a00dd0aa4340c1fb73e>
09:05:31.806290 INFO Wrong index in transaction inputs: 432, expected maximum 430
09:05:31.806462 INFO Failed to get output keys for tx with amount = 20.00000000 and count indexes 1
09:05:31.806571 INFO Failed to check ring signature for tx <1d3a9cfb8498a2e2adb2837f81953b1057815d1baa245a00dd0aa4340c1fb73e>
09:05:39.436347 INFO Wrong index in transaction inputs: 432, expected maximum 430
09:05:39.436472 INFO Failed to get output keys for tx with amount = 20.00000000 and count indexes 1
09:05:39.436536 INFO Failed to check ring signature for tx <1d3a9cfb8498a2e2adb2837f81953b1057815d1baa245a00dd0aa4340c1fb73e>

Bad TXN in question:

print_tx 1d3a9cfb8498a2e2adb2837f81953b1057815d1baa245a00dd0aa4340c1fb73e

{"":"1f3bcdfe56e543669cd7fba73645d316903435ded44515de0176a5242615c20b9b4e25b6a33004cfb2c80f368549232deda2e306bc133ff4e18f672d50537a03","extra":"01d7ca20702b365658491ff9b86161701a190e47ddf1c289aca89c621efe197de8","unlock_time":0,"version":1,"vin":[{"type":"02","value":{"amount":100000000000,"k_image":"c073faaf23ffaee38624cf0928290f71431c5930076ef89df6e2712d15785d32","key_offsets":[1753]}},{"type":"02","value":{"amount":90000000000,"k_image":"a7322aef508a3f7341824d329334eef40c1de81bbc2e97c40e085f9069cf8395","key_offsets":[1577]}},{"type":"02","value":{"amount":100000000000,"k_image":"e2dce6e6a88e380d380060ee45b82c40eeecef2f776edf362a318dde2a86af78","key_offsets":[1725]}},{"type":"02","value":{"amount":2000000,"k_image":"74f187b0744202bdf058423fe21fe49f4fa5eb16df47771c2369ba2e358bd607","key_offsets":[225]}},{"type":"02","value":{"amount":300000,"k_image":"475610b0f290744b3867bedfa24a06b2a9cd32fd073d36af755187d7812f8897","key_offsets":[227]}},{"type":"02","value":{"amount":50000,"k_image":"1224a2ff9829de462a6f85e0a77ce8b2280f40a108def7f33cc61ec69568a462","key_offsets":[69]}},{"type":"02","value":{"amount":2000000,"k_image":"3fe9c302a1acdc981b267ed1e65fece4fa29c3b6d1b78b92ec85bdd450065759","key_offsets":[222]}},{"type":"02","value":{"amount":2000000000,"k_image":"d5f41b8d7adfe409775862db202a67f2e9f4c5f5e7779c63a63d2c4537243311","key_offsets":[432]}},{"type":"02","value":{"amount":400,"k_image":"a64b8f3f7a68377ebbf6dd0021b1b763f3c3ffd6f32aa5040a9e040dfcbb557d","key_offsets":[82]}},{"type":"02","value":{"amount":90000000000,"k_image":"bf9ccc068cf338c9d3d2257b0cf7470b3c727577c648cca6a55d2ad5e7d32cf3","key_offsets":[1583]}},{"type":"02","value":{"amount":100000,"k_image":"73dfe705b7cfd6d0718f88f33fb829dae43c25142259dbaa4436e62354c7345e","key_offsets":[263]}},{"type":"02","value":{"amount":100000000000,"k_image":"f20127620c894fb28f753f165b3367773265a035eda07506fed3736bba128437","key_offsets":[1745]}},{"type":"02","value":{"amount":600000,"k_image":"b47c861a75d54198ba9caf329ad3f8eb6101401c1bacb1a05fed141f8c1254c9","key_offsets":[219]}},{"type":"02","value":{"amount":100000000000,"k_image":"8f3184cdd6c055e3c90fc3f7c8d553d2e6aaf8f569912882c294ea458794d834","key_offsets":[1722]}}],"vout":[{"amount":400,"target":{"data":{"key":"640b382b920600edd7c700eea2f668f8540627563fcb96fb39b878049cc97b66"},"type":"02"}},{"amount":50000,"target":{"data":{"key":"17f7c388283a84b575315cd0c094120d0f4e8c09ea9261fb8ff5d4d02d6022d9"},"type":"02"}},{"amount":5000000,"target":{"data":{"key":"ad6462fb921e1c1da2f5e367c367987a0465142b2762e57abfa357a061e8dcc0"},"type":"02"}},{"amount":90000000,"target":{"data":{"key":"440da8bf9ee0648b9505013941a1f0baac3056206f4aad36d82e435fe4079445"},"type":"02"}},{"amount":500000000,"target":{"data":{"key":"481c7150bd3d29497c00ceca7d99c9e2cacc84dad0a32357b4f36a02f82d8a2c"},"type":"02"}},{"amount":500000000,"target":{"data":{"key":"618e027998b613cd3ef0a7404280b1e3f90b2591aab7da82276d907952e6c597"},"type":"02"}},{"amount":900000000,"target":{"data":{"key":"a95d786665c5e520c440bfa191ae56c3d9d45f512f75320c020934154c37de1a"},"type":"02"}},{"amount":1000000000,"target":{"data":{"key":"11bd898926cd55f1c2640af8ada2a199884fba0a147748aef48da2b33ed068d1"},"type":"02"}},{"amount":5000000000,"target":{"data":{"key":"6583a677174b21c66162f167d321d44d3ca1abcac48c14fafc78ead77c1a81a1"},"type":"02"}},{"amount":6000000000,"target":{"data":{"key":"99370d214470971c42214060f7bd52a75afa2d99a4716e8ffafb679cdbf52031"},"type":"02"}},{"amount":8000000000,"target":{"data":{"key":"65e5bb18883bf71402ae6d92ad69ceba5a5a646e5f8279d78017c2e6cce68a1d"},"type":"02"}},{"amount":20000000000,"target":{"data":{"key":"cc422ef41f9d800f3e637309d0e76141424802106c8660756475ff4b5adcca2e"},"type":"02"}},{"amount":20000000000,"target":{"data":{"key":"739e5b34b0cfa34a067ce5efef0387aa9d7cde92bc379c1522bd25291f443fdc"},"type":"02"}},{"amount":40000000000,"target":{"data":{"key":"63a191443ec402e1ead37ed71f4436e929ca162b74f5fd5e6bd1672cad479060"},"type":"02"}},{"amount":80000000000,"target":{"data":{"key":"57a24e804a1eb75014196242aadd05d8378ddd4866b3516580a195a345239014"},"type":"02"}},{"amount":400000000000,"target":{"data":{"key":"b869c8ab828f98ac21f88d42110b73493c30a63324126d72f5a9ea571d7076dd"},"type":"02"}}]}

Of which the offending portion seems to be:

{  
         "type":"02",
         "value":{  
            "amount":2000000000,
            "k_image":"d5f41b8d7adfe409775862db202a67f2e9f4c5f5e7779c63a63d2c4537243311",
            "key_offsets":[  
               432
            ]
         }
      },

As far as I can tell, these issues always begin with the pool daemon complaining about a block size that is too big. The problem is that simplewallet in RPC mode will sporadically, about every 4-8 hours, produce a bad transaction. The bad txn seems to follow a notification about the blockchain producing a block that is too large. The system it's running on initially complains of an error like so in the daemon:

2017-Aug-18 09:22:36.051612 INFO [Blockchain] Block <7c7dc54b51d0b355c6bf9e355229bc252a8931ddc70ba43f52fbc8dc1571a6db> is too big: 21127 bytes, exptected no more than 21057 bytes

After that, the next transaction that is attempted to be sent fails:

2017-Aug-18 09:22:50.663591 INFO [Blockchain] Block <6013e74ced7e0191f75c4b60068175f83ef12499b5ceb167d15308853e562416> has at least one transaction with wrong inputs: <4af78d565558395ad0c965df98f4bb0e66fa0aaa1a29091e0275f6cda3eb7fba>

I am not sure if the blockchain or daemon is auto truncating the block since it's too big, leading to further downstream issues. This causes a fork eventually and stops the daemon from making more blocks.