Web3j only supports 1 transaction per block

[tramonex-nate]

Due to the behaviour of getNonce in ManagedTransaction.java:

    protected BigInteger getNonce(String address) throws InterruptedException, ExecutionException {
        EthGetTransactionCount ethGetTransactionCount = web3j.ethGetTransactionCount(
                address, DefaultBlockParameterName.LATEST).sendAsync().get();

        return ethGetTransactionCount.getTransactionCount();
    }

If more than 1 transaction is sent per block, the nonce will be incorrect (all transactions sent in the same block will have the same nonce). This will lead to all transaction but one being invalid.

Suggestion:
Maintain a count of how many transactions have been sent from the address for the current block, and return ethGetTransactionCount.getTransactionCount() + sentTransactionCount. This could still lead to problems in various situations, but would be an improvement. Really open to alternate solutions

[conor10]

@ferOnti would you be willing to share your implementation?

#34 (comment)

[ferOnti]

@conor10 the implementation is not ready yet, because still having the issue "rlp: non-canonical integer (leading zero bytes) for *big.Int, decoding into (types.Transaction)(types.txdata).S”

for this reason I'm losing some transactions from time to time. Since I'm in proof of concept this is enough for this state.

Later this week I will revisit this feature and work in the nonce manager. I will keep you posted on this.

[conor10]

Was my previous response of help?

Is there a quantity value in your pre-encoded request that is being specified with a leading zero, e.g. 0x0... - as these are not supported in the JSON-RPC API - see https://github.com/ethereum/wiki/wiki/JSON-RPC#hex-value-encoding.

[ferOnti]

Hi Conor, About this issue, I found where the error is, The error is in TransactionEncoder.java file, in this screenshot , you will see the getS() is returning a bytes[] and then in line 86 is calling the RlpString.create() function but the argument is a bytes[] I checked the constructors for RlpString.create and there is one for BigInteger, and this function has a "leading zero protection” but, since line 86 is calling like bytes[], the constructor for bytes does not have this “leading zero” protection, so, the fix should be convert first to BigInteger, and then call the constructor, and then we will not have this issue. Please let me know if you can fix that, I think all numbers should be converted to big integer before create the RLP representation, and according to Yellow Paper, the R values is also a big integer. By the way, I’m passing to Quorum in my researching, and I sow your repository for quorum, (i will check it also, now) Thanks

…

On Jan 16, 2017, at 7:05 PM, Conor Svensson ***@***.***> wrote: Was my previous response of help? Is there a quantity value in your pre-encoded request that is being specified with a leading zero, e.g. 0x0... - as these are not supported in the JSON-RPC API - see https://github.com/ethereum/wiki/wiki/JSON-RPC#hex-value-encoding <https://github.com/ethereum/wiki/wiki/JSON-RPC#hex-value-encoding>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABmjKxpHRzgXB9iX2Crgw6kHOQu9fS5Yks5rS_eugaJpZM4LhyQ->.

[conor10]

@ferOnti RLP issue fix has just been checked in, see https://github.com/web3j/web3j/blob/master/src/main/java/org/web3j/rlp/RlpString.java#L25 for details.

Re: web3j-quorum, the API for working with smart contracts in Quorum is going to get a lot simpler when I put out the web3j 1.2.0 release in the next week. All that will be required is a Quorum transaction manager instead of a Quorum specific smart contract code generator as is currently the case.

[conor10]

Initial implementation checked in - see https://github.com/web3j/web3j/blob/master/src/main/java/org/web3j/tx/FastRawTransactionManager.java & associated integration test https://github.com/web3j/web3j/blob/master/src/integration-test/java/org/web3j/protocol/scenarios/FastRawTransactionManagerIT.java.

[fraspadafora]

Why to mantain a local nonce and increment it?
If with another client I'm creating transactions there can be a problem.

As I suggested here : #54
You can use the method:

web3j.ethGetTransactionCount(address, DefaultBlockParameterName.PENDING)

That returns the number of transactions validated and in pending, so after you create a transaction you can receive the nonce updated.

[tramonex-nate]

Have you tested this? According to my knowledge of how the 'pending' block parameter name works, it's actually the block that the target node is mining (which will not be anything if the node is not mining)

[ferOnti]

I had some doubts about use this, but I will test now

[fraspadafora]

From: https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethdefaultblock

"pending", the currently mined block (including pending transactions)

[ferOnti]

I tested with these two alternatives, but the web3j.ethGetTransactionCount(address, DefaultBlockParameterName.PENDING) is repeating the nonce many times

The first graph is using the PENDING option, and as you can see the log in the line Web3Service:988 is repeating the nonce many times ( 969 three times, 971 five times, etc )

This second graph, is getting the nonce from the HQTransactionManager , and the nonce is not repeated

when the nonce is repeated, the transactions are overwritten and they are not included in any block.

I will post the HQTransactionManager with the second option

[fraspadafora]

Can you check using the RawTransactionManager class but making the executeTransaction method synchronized?

I think using the synchronized method solves the problem.

As I said here: #54

In the FastRawTransactionManager If I use another client with the same account and I send a transaction, the nonce in the will be not updated and all transactions will be invalid.

[scalahub]

Is this solved? I am getting outdated nonces with DefaultBlockParameterName.LATEST. Right now I have no other option but to maintain a list internally.. kind of writing a client.