No Transaction Occuring [SOLVED]

I guess Python 3.6 has issues with keccak_224, I’m on Python 3.5 and no problems. A quick search shows it could be this : https://www.google.com/search?client=ubuntu&channel=fs&q=python+3.6+keccak_224&ie=utf-8&oe=utf-8

I’m facing exactly the same issue.
Running on Docker and trying on ropsten.

I debugged it and saw the URL in this format.

https://api-ropsten.etherscan.io/api?module=proxy&action=eth_sendRawTransaction&hex={YOURSIGNEDTX}&apikey=YourApiKeyToken

(Tx hex is - f884808504a817c8008261a894deaddeaddeaddeaddeaddeaddeaddeaddeaddead80a08c25ff2b66bb52fbaeef43389edc7fca959c23c7f8cf2abb5aed630c0bb043c32aa0456454562ccb1f706337c4b25e4ec13d6ef5385772a5716ad20351dad38a71d8a006aa74bfc0b427b27a716f0d7095f2275b9a3f77c5a9482f828fa017e0dfc882)

When I read the POST response, it fails with
{‘jsonrpc’: ‘2.0’, ‘error’: {‘code’: -32010, ‘message’: ‘Insufficient funds. The account you tried to send transaction from does not have enough funds. Required 500000000000000 and got: 0.’}, ‘id’: 1}

(Which is pretty weird because, I checked the account balance using the ropsten api format (as shown below) and I got the balance of 1ETH. which is its correct balance)

response = requests.post(‘https://api-ropsten.etherscan.io/api?module=account&action=balance&address={MyWalletAddress}&tag=latest&apikey={MyAPIKEY}’)
And, the respose is,
{‘status’: ‘1’, ‘message’: ‘OK’, ‘result’: ‘1000000000000000000’}

@GuillaumeDuveau @Palash-A @aronning
{‘jsonrpc’: ‘2.0’, ‘error’: {‘code’: -32010, ‘message’: ‘Insufficient funds. The account you tried to send transaction from does not have enough funds. Required 500000000000000 and got: 0.’}, ‘id’: 1}

Does this mean its trying to broadcast to mainnet instead of ropsten?
But, I have debugged it and checked, it has netcode= 3 when executing…

@dev @Palash-A

Go here for some troubleshooting: https://npm.runkit.com/ether.js?q=etherjs

and input this:

var ethers = require('ethers');
var Wallet = ethers.Wallet;
  
raw = '0x{YOURSIGNEDTX}'

var transaction = Wallet.parseTransaction(raw); 

From the looks of it, when decoded, your transactions are on ropsten, but the FROM address shows addresses that do not show any funds. Verify whether or not the FROM address is correct. If it is, then you really don’t have funds. If it’s not, then there’s an issue signing the transaction, probably sha3 related.

@dev - so you’re running into this issue with the Docker image too? By chance, do you get the

INFO - This run will try to issue on the ethereum_ropsten chain
/usr/local/lib/python3.6/site-packages/merkletools/init.py:7: UserWarning: sha3 is not working!
warn(“sha3 is not working!”)

error like @Palash-A posted?

@aronning
Nopes. I don’t get the sha3 is not wokring error.

Here’s my console log while trying to issue certificates.

bash-4.3# python3 cert_issuer -c conf_ethtest.ini

WARNING - Your app is configured to skip the wifi check when the USB is plugged in. Read the documentation to ensure this is what you want, since this is less secure
INFO - This run will try to issue on the ethereum_ropsten chain
INFO - Set cost constants to recommended_gas_price=20000000000.000000, recommended_gas_limit=25000.000000
INFO - Set cost constants to recommended_gas_price=20000000000.000000, recommended_gas_limit=25000.000000
INFO - Processing 2 certificates
INFO - Processing 2 certificates
INFO - Processing 2 certificates under work path=data/work
INFO - Processing 2 certificates under work path=data/work
INFO - Balance check succeeded: {‘status’: ‘1’, ‘message’: ‘OK’, ‘result’: ‘1000000000000000000’}
INFO - Balance check succeeded: {‘status’: ‘1’, ‘message’: ‘OK’, ‘result’: ‘1000000000000000000’}
INFO - Total cost will be 500000000000000 wei
INFO - Total cost will be 500000000000000 wei
INFO - Starting finalizable signer
INFO - Starting finalizable signer
WARNING - app is configured to skip the wifi check when the USB is plugged in. Read the documentation to ensure this is what you want, since this is less secure
WARNING - app is configured to skip the wifi check when the USB is plugged in. Read the documentation to ensure this is what you want, since this is less secure
INFO - Stopping finalizable signer
INFO - Stopping finalizable signer
WARNING - app is configured to skip the wifi check when the USB is plugged in. Read the documentation to ensure this is what you want, since this is less secure
WARNING - app is configured to skip the wifi check when the USB is plugged in. Read the documentation to ensure this is what you want, since this is less secure
INFO - here is the op_return_code data: 8c25ff2b66bb52fbaeef43389edc7fca959c23c7f8cf2abb5aed630c0bb043c3
INFO - here is the op_return_code data: 8c25ff2b66bb52fbaeef43389edc7fca959c23c7f8cf2abb5aed630c0bb043c3
INFO - Nonce check went correct: {‘jsonrpc’: ‘2.0’, ‘result’: ‘0x0’, ‘id’: 1}
INFO - Nonce check went correct: {‘jsonrpc’: ‘2.0’, ‘result’: ‘0x0’, ‘id’: 1}
INFO - Starting finalizable signer
INFO - Starting finalizable signer
WARNING - app is configured to skip the wifi check when the USB is plugged in. Read the documentation to ensure this is what you want, since this is less secure
WARNING - app is configured to skip the wifi check when the USB is plugged in. Read the documentation to ensure this is what you want, since this is less secure
INFO - Stopping finalizable signer
INFO - Stopping finalizable signer
WARNING - app is configured to skip the wifi check when the USB is plugged in. Read the documentation to ensure this is what you want, since this is less secure
WARNING - app is configured to skip the wifi check when the USB is plugged in. Read the documentation to ensure this is what you want, since this is less secure
INFO - signed Ethereum trx = f884808504a817c8008261a894deaddeaddeaddeaddeaddeaddeaddeaddeaddead80a08c25ff2b66bb52fbaeef43389edc7fca959c23c7f8cf2abb5aed630c0bb043c32aa0456454562ccb1f706337c4b25e4ec13d6ef5385772a5716ad20351dad38a71d8a006aa74bfc0b427b27a716f0d7095f2275b9a3f77c5a9482f828fa017e0dfc882
INFO - signed Ethereum trx = f884808504a817c8008261a894deaddeaddeaddeaddeaddeaddeaddeaddeaddead80a08c25ff2b66bb52fbaeef43389edc7fca959c23c7f8cf2abb5aed630c0bb043c32aa0456454562ccb1f706337c4b25e4ec13d6ef5385772a5716ad20351dad38a71d8a006aa74bfc0b427b27a716f0d7095f2275b9a3f77c5a9482f828fa017e0dfc882
INFO - verifying ethDataField value for transaction
INFO - verifying ethDataField value for transaction
INFO - verified ethDataField
INFO - verified ethDataField
/usr/lib/python3.6/site-packages/cert_issuer/blockchain_handlers/ethereum/connectors.py(69)broadcast_tx()
-> broadcast_url = self.base_url + ‘?module=proxy&action=eth_sendRawTransaction’
(Pdb) c
INFO - Transaction ID obtained from broadcast through Etherscan: None
INFO - Transaction ID obtained from broadcast through Etherscan: None
INFO - Broadcast transaction with txid None
INFO - Broadcast transaction with txid None
INFO - Your Blockchain Certificates are in data/signed_certificates
INFO - Your Blockchain Certificates are in data/signed_certificates`

Based on your signed transaction, your FROM address is showing as 0xDC61C7F2Cb37Ec6aD537413eD3A9959de8C11a0d

Is that correct?

Meanwhile,
@aronning

Using the Node.js tool,
the from address in the signedTx is actually the recipient’s address. Not the issuer address!!

Explaining what I did, I have issuer address in conf file (this has 1 rETH) and generated unsigned certificate using cert-tools and a recipient address (which has 0 rETH).
But, the signedTx is trying to do a transaction from the recipient address to the burn address!!

Okay interesting. What that might imply to me is that the private key you’re using in the docker image might actually be that of the recipient’s address?

Hmm. Let me check on that.

Meanwhile,
Shouldn’t it just fail trying to verify because issuer address and private key don’t match?

You’re correct, the certificate won’t verify in the end. But this is the issuing step, and there’s no verification done at this step.

I tested out what would happen if I set an issuing address in the config, fund it, then stick a private key that does not match the issuing address, I get the same problem as you.

Ah Cool.
So, I put in the correct key now.
And tried to issue the certificates, It broadcasted and returned a successful transaction ID - 0xb26c7b576e56249021927c94eddc7acc032c7aca6d5c887e90923f02c9b5c6ab

Its still transferring to the burn address (0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddead) that is hard-coded in the code though…

Correct, we do not send the transactions to the recipient addresses. We send the transaction to a burn address, with the data of that transaction corresponding to the hash of the certificate.

In our case, we care about the transaction ID and the data in that transaction. Not the address it goes to.

Oh…

From the main workflow, I got a notion that, once the issuer notifies the recipient, the recipient sends their public address, and then we use that to issue the certificate.

With this I assumed that the transaction will be sent to the recipient’s address.
But, we just use that recipient address to hash along with the certificate’s content?

Meanwhile,

@Palash-A

Check this out. This was the supposed fix it seems (for windows and mac machines). And, I think you are not using docker, so this might be the fix you are looking for.

Try importing as _pysha3 and check?

Yup! You have that correct. If you check the signed json file, you’ll see that the recipient address is in there.

1 Like

Yes I know I can’t do that. My point was to check whether the other imports were working in the file or not and whether keccak_224 was used by cert-issuer. I wanted to see if sha_224 would be used instead.

Yup. I got my certificates to issue on Python 3.5

I did change the requirements of pysha3 in /lib/python3.5/site-packages/merkletools-1.0.2-py3.5.egg/EGG-INFO/requires.txt from pysha3==1.0b1 to pysha>=1.0.2 though.

Hey @aronning I changed my issuing address and its private key to a new account and got my certificates to issue [tx]. However, I also changed the pysha3 requirements of merkeltools-1.0.2 at the same time like an idiot and hence, don’t know which fixed the issue. Although, my guess is changing pysha3 requirement did the trick. Did you update at your end as well @dev?

One thing I did notice was that the signed-certificates directory (work directory and otherwise) is always empty. Is that supposed to happen? If so, why ask us to create one?

Another user brought that up recently. I think that might be a typo somewhere, it should be in the blockchain_certificates when ready.

@Palash-A
Great!

I didn’t have an issue with pysha3. So didn’t update that.
My issue was mismatch between public and private keys. After fixing that, we were able to issue the certificates.