Lottery always returen to me winner is 0x0000000000000000000000000000000000000000

[mohzourob]

I have tried to increase wait time from 60 to 120 but always give me the same response 0x0000000000000000000000000000000000000000 ?? why ??

[cromewar]

Hey @dash7ou I had the same problem, this happens because brownie is not taking the correct account it should, I don't know how advanced you are on the lottery project but I have some suggestion for you:

1. Make sure your get_account function seems like this:

FORKED_LOCAL_ENVIRONMENTS = ["mainnet-fork", "mainnet-fork-fev"]
LOCAL_BLOCKCHAIN_ENVIRONMENTS = ["development", "ganache-local"]

def get_account(index=None, id=None):
    # for specific account into the ganache-cli testnet accounts
    if index:
        return accounts[index]
    # For specific account configured on brownie accounts
    if id:
        return accounts.load(id)
    if (
        network.show_active() in LOCAL_BLOCKCHAIN_ENVIRONMENTS
        or network.show_active() in FORKED_LOCAL_ENVIRONMENTS
    ):
        # for any of the local or forked environemnts return the account with index zero
        return accounts[0]

    # Default option, load from config file

    return accounts.add(config["wallets"]["from_key"])

2. Make sure your brownie-config.yaml looks like this:

dependencies:
  - smartcontractkit/[email protected]
  - OpenZeppelin/[email protected]
compiler:
  solc:
    remappings:
      - '@chainlink=smartcontractkit/[email protected]'
      - '@openzeppelin=OpenZeppelin/[email protected]'
dotenv: .env
networks:
  default: development
  development:
    keyhash: '0x2ed0feb3e7fd2022120aa84fab1945545a9f2ffc9076fd6156fa96eaff4c1311'
    fee: 100000000000000000
  rinkeby:
    vrf_coordinator: '0xb3dCcb4Cf7a26f6cf6B120Cf5A73875B7BBc655B'
    eth_usd_price_feed: '0x8A753747A1Fa494EC906cE90E9f37563A8AF630e'
    link_token: '0x01BE23585060835E02B77ef475b0Cc51aA1e0709'
    keyhash: '0x2ed0feb3e7fd2022120aa84fab1945545a9f2ffc9076fd6156fa96eaff4c1311'
    fee: 100000000000000000
    verify: True
  mainnet-fork:
    eth_usd_price_feed: '0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419'
wallets:
  from_key: ${PRIVATE_KEY}

3. Your end_lottery should look like this:

def end_lottery():
    account = get_account()
    lottery = Lottery[-1]
    # fund de contract and  end the lottery
    tx = fund_with_link(lottery.address)
    tx.wait(1)
    ending_transaction = lottery.endLottery({"from": account})
    ending_transaction.wait(1)
    time.sleep(60)
    print(f"{lottery.recentWinner()} is the winner!")
    print("Lottery ended successfully")

If you want to use your own test account don't forget to add id=name-of-your-brownie-account on each get_account call.

Finally, deleting the build folder and compiling again always helps.

Best regards.

[Programproductions]

I had a similar problem. So I went back and checked my code in some other places. The new element here was deploying to the Rinkeby testnet, as all unit test had passed. So I checked my config file and it turned out I had the wrong keyhash for Rinkeby. Once I changed it to the same as the one in the Github repo it passed straight away - with sleep set to 60 as well.

So if you get this error at this stage try checking your settings for deployment to Rinkeby, including your .env variables, as well as your config :)

[cromewar]

Yeah @Programproductions a single digit could ruin entirely the execution that's why I recommended all that steps, I hope @dash7ou will be able to solve the problem.

[mohzourob]

@cromewar @PatrickAlphaC, I cloned the orginal repo for smartcontract-lottery and run it but give me the same result

0x0000000000000000000000000000000000000000 is the new winner!

[PatrickAlphaC]

Try 300 seconds.

[MED-1996]

sleeping for 300s worked for me too^ thanks!

[siddharthalodha]

I guessed that it would be taking a lot more time to get the winner. I waited and verified directly from etherscan.

[neerajnerlekar]

300s worked for me too. Thank you.

[cromewar]

Hey @dash7ou I managed to reproduce the error , it seems it happens when you deploy the contract using the development network, with ganache.

However deploying the same contract on the rinkeby network works fine:

I'm not sure why this is happening on the development network as get_account should return accounts[0] from the local ganache instance, I'll try to do further research.

[PatrickAlphaC]

Nice work :)

[mohzourob]

@cromewar No, that is not right I am using rinkeby network not working fine.

[mohzourob]

@cromewar @PatrickAlphaC u can check ss.

[cromewar]

That's weird as I cloned and run the same repo, however even if the terminal response does not give you the winner you may check directly on the Rinkeby Ether Scan, for example this is the the contract I've deployed on the screenshot yesterday:

https://rinkeby.etherscan.io/address/0xD47F72E2Fb58d798B8af947701Ab60c0cf9289aD

Could you please try again and check if the lottery completes successfully on EtherScan?

Note: this is not related at all, but I have to say is nice to see someone using Kali.

[mohzourob]

I think that related to time, I need to increase time maybe change it to 300 seconds as @PatrickAlphaC recommend.

Note: this is not related at all, but I have to say is nice to see someone using Kali.

LOL, what did you expect from Senior developer & DevOps Eng, I am not one of the kids :P

[mohzourob]

@PatrickAlphaC @cromewar
After I increased the time it is works fine

0x2fFba8944bDE50E944A927C803E052d8bEa04892 is the new winner!

But now my question is how can I trust something like that, why there is no blocking until getting this response
maybe like async requests and wait for it until the response returns back?

[cromewar]

oh, well, as the transaction may take while to complete and you are using a print statement on python you just use that wait time to let the transaction to be processed, as you said and asynchronous call may be a more elegant solution.

[mohzourob]

@cromewar there is something missing,,

@PatrickAlphaC So what do u think?

[PatrickAlphaC]

Nice work all! Glad you all came to the solution :)

So us doing time.wait() and picking some random number was just a cheeky workaround. 100% you're right when you say for a more robust solution we should listen to the blockchain for events to fire. The reason I didn't go into that in this course was I didn't want to teach people async, as the course was long enough, and async has a whole load of other things we have to keep in mind. With the unit tests, you don't have to do this, it's only the integration tests.

If you want to learn how to wait for events with asyncio this guide can help: https://cryptomarketpool.com/how-to-listen-for-ethereum-events-using-web3-in-python/

It sounds like it would be a cool brownie improvement to add like a "wait for event" function with a timeout.

[mohzourob]

@PatrickAlphaC Thanks!, I will read this article and give u my impression of it.

[Sevamove]

I met the same issue time ago. Glad that you solved this too.

PatrickAlphaC/smartcontract-lottery#12