PrivateMinerSample, send transaction
bartmark opened this issue · 8 comments
I am sucessfully running the PrivateMinerSample. Two nodes started up, the second one is sending a transaction which gets DROPPED by the miner due to insufficient cash.
This is the line in the logs:
14:15:00.351 DEBUG [pending] PendingTransactionUpdate: (Tot: 0) DROPPED : 921665f0 0 #848 (9ad44f <~ dbd8b0) Txs:0, Unc: 0 [Not enough cash: Require: 52428750000000077, Sender cash: 0]
I'm just wondering if this sample is broken (or at least the part with the transaction) or what is going wrong here.
Any help would be appreciated.
I think i found an issue. I changed crypto.hash.alg256 and crypto.hash.512 to SHA-256 and SHA-512. It looks like then is something broken regarding access to the balance of the address
[Not enough cash: Require: 52428750000000077, Sender cash: 0]
Isn't it about zero balance of the account you try to send value from?
No, the account is premined. If i just run PrivateMinerSample without any changes it's working. But if i change the configuration to
#crypto settings, such as sign, hash, etc
crypto {
#JCA cryptoprovider name.
providerName="SC"
#Used for create JCA MessageDigest
hash.alg256="SHA3-256"
hash.alg512="SHA3-512"
}
the balance is 0.
You can try it by your own by changing your crypto config.
@bartmark you are changing crypto config, so wallet associated with the same private key is changed, because algorithm is changed, it's expected behaviour
Well, after changing my crypto configuration i started a new blockchain (deleted the database folders), so i would suggest that it should work. Is the address in the genesis file depending on the hash algorithm?
@bartmark address in genesis is not changed, but such things
ECKey senderKey = ECKey.fromPrivate(Hex.decode("6ef8da380c27cea8fdf7448340ea99e8e2268fc2950d79ed47cbf6f85dc977ec"));
produces another derived address as algo is changed. So you are getting access to another address which is not included in premine.
Changing hashing algorithm affects signature schema but must not change the pub key that is recovered from signed transaction. Thus, it must not affect the whole flow. This issue needs further investigation.
Ah, a stupid thing. I missed a fact that address is last 20 bytes of hash of a pubKey. Thus, address indeed depends on the hashing algorithm.