Stakepool registration on Pending for long time (30+ mins)

[edescourtis]

Not resolved by #558 .

- fragment_id: c796d89c3563a1e76ccf21965acc8264646fc62af955fd184f0dd79f497dc192
  last_updated_at: "2019-12-15T17:19:11.694739403+00:00"
  received_at: "2019-12-15T17:19:11.694738939+00:00"
  received_from: Rest
  status: Pending

[edescourtis]

What can I do? Others are in the same situation.

[stakeada]

This is definitely an issue, tried with the #558 as well, but the problem doesn't get away!

[stakeada]

Steps to reproduce:

1. Running cardano-wallet jormungandr:

# cardano-wallet launch --genesis-block-hash $(cat genesis-hash.txt) -- --config itn_rewards_v1-config.yaml

Running also the jormungandr - both are itn_rewards_v1 using 8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b676 genesis hash:

# jormungandr --config ./stakepool-config.yaml --genesis-block-hash $(cat genesis-hash.txt)

2. Have a wallet that has 1000 ADA. This is surely enough for setting up a stake pool. This is available in https://shelleyexplorer.cardano.org/ and can input owner.addr to see it.

3. Create KEYS:

# jcli key generate --type=Curve25519_2HashDH > vrf.prv
# jcli key to-public < vrf.prv > vrf.pub
# jcli key generate --type=SumEd25519_12 > kes.prv
# jcli key to-public < kes.prv > kes.pub

4. Create stake pool cert:

# jcli certificate new stake-pool-registration --tax-fixed 0 --tax-ratio "1/20" --kes-key $(cat kes.pub) --vrf-key $(cat vrf.pub) --owner $(cat owner.pub) --start-validity 0 --management-threshold 1 > stake-pool-registration.cert
# jcli certificate get-stake-pool-id < stake-pool-registration.cert | tee stake_pool.id

5. Compute pledge amount, which is the sum of the below and is 500700000

# export FEE_CONSTANT=200000
# export FEE_COEFFICIENT=100000
# export FEE_POOL_REGISTRATION=500000000
# export FEE_STAKE_DELEGATION=400000
# export GENESIS_HASH=8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b676

5. Prepare transaction:

# jcli transaction new | \
  jcli transaction add-account $(cat owner.addr) $PLEDGE_AMOUNT  | \
  jcli transaction add-certificate $(cat stake-pool-registration.cert) | \
  jcli transaction finalize $(cat owner.addr) \
    --fee-constant $FEE_CONSTANT \
    --fee-coefficient $FEE_COEFFICIENT \
    --fee-pool-registration $FEE_POOL_REGISTRATION \
  > transaction.tmp

# jcli transaction make-witness \
  $(jcli transaction data-for-witness < transaction.tmp) \
  --genesis-block-hash $GENESIS_HASH \
  --type account \
  --account-spending-counter 0 \
  owner.witness \
  owner.prv

# jcli transaction add-witness owner.witness < transaction.tmp \
  | jcli transaction seal \
  | jcli transaction auth -k owner.prv \
  | jcli transaction to-message \
  > transaction.bin

# jcli rest v0 message post --host http://localhost:3101/api --file transaction.bin

The ID returned by the last command is then stuck in "Pending" state and the pool ID is never created!

Note that I've used the same owner.addr|prv|pub and have completed those steps a couple of times, so it may be the case that a transaction went through. However, can the same owner.addr|prv|pub create multiple stake pools and then just use one of them? In any case, I've done this today 3-times and the transaction was in Pending state for 1 hour, then it went away and the stake pool ID is not visible in shelley explorer, which means it failed.

[stakeada]

CC @admin-cf @KtorZ @cardanohawaiipool

[stakeada]

If I follow the exact same instructions by using a different address to which I've sent 500 ADA, then everything works okay. I guess it's something to do with my initial address. Can the same owner.addr repeat 3/4/5 steps above to create a new transaction, effectively creating a new stake pool, while one already exists?

[wstrik]

Same issue here

[Myriada]

OK i just re-ran the createStakePool.sh from a synced jormungandr node (0.8.3) and it now shows up in the explorer.

[KtorZ]

@stakeada Can the same owner.addr repeat 3/4/5 steps above to create a new transaction, effectively creating a new stake pool, while one already exists?

In theory yes. In practice, if it's an account address, you need to adjust the account counter for every new transaction. I am not sure how Jörmungandr would behave in case you pass in a wrong counter. Jörmungandr has a tendency to "accept" transactions via the REST API and ignore them later when they are analyzed by the ledger.

Also, the "PLEDGE_AMOUNT" should be greater than the minimal fees AND match your account balance. Otherwise, the transaction will be deemed invalid. Incidentally, minimal fees are likely to be: 500800000 because, your transaction will typically have a change output (the input itself), which makes for 2 inputs/outputs in total (and therefore, 2 x FEE_COEFFICIENT, plus the rest).

Closing the ticket as the issue seems resolved.