Update request/response data structs to include extra fields
Refactor the SendTransactionAsync method to just call the
SendTransaction method in a goroutine, instead of reimplementing logic
for a new transaction.
* Used Tessera as a fall back when Constellation is not available in the host
* Used OSX 10.12 instead of 10.13 to avoid Kernel Extension Consent which is not available in CI environment. Can revert back once Travis CI has ability to disable the consent
* Merged upstream PR/Code to fix tests which have intermittent failures
* Cleaned up .travis.yml build matrix
Previously we had populated the public receipt `failed` field with the
result of the transaction. This is correct for public transactions. It's
also correct for successful private transactions. But it's not correct
for failing private transactions, because their public receipt should
not indicate failure. The fix is straightforward.
Testing:
I used this contract:
contract RevertTest{
uint public newValue;
function revertFunction() public{
uint a = 1;
require(a == 0);
}
}
After deploying the contract I sent in several failing transactions via
function sendBad() {
eth.sendTransaction({
from: eth.accounts[0],
data: web3.sha3("revertFunction()"),
gas: 0x47b760,
privateFor: ["ROAZBWtSacxXQrOe3FGAqJDyJjFePR5ce4TSIzmJ0Bc="]
});
}
Watching the logs (`1.log` and `2.log`), I saw the `TX-ACCEPTED` events
scroll as I sent `revertFunction` transactions. I see 10 `TX-ACCEPTED`
events in both logs (1 for deploy and 9 tests via `sendBad`).
Via extra logging, in `1.log` I see that the public receipts have status
`1`, whereas private receipts have status `0`. In `2.log` they all have
status `1`.
All nodes stayed up the whole time.
Fixes#434
Always use the EIP155 signer for verifying new transactions being added
to the transaction pool and only skip protected public transactions from replay attacks until
we reach EIP155 activation.
* keep merging of public and private receipts inline with other processing flows
* added private state prepare in commitTransaction for missed private events
The scenario is covered in https://github.com/jpmorganchase/quorum/issues/428, but in short, if
we're mining but two new blocks come in over the network:
(1) The first will clear the speculative chain.
(2) The second previously would have been a noop here --
`removeProposedTxes` does nothing in this case, but we need to update
the speculative chain head to the new block.
The important invariant identified by @guojian1234 that this now
maintains is
`minter.speculativeChain.head.blockNumber >= minter.chain.head.blockNumber`.
Peter Fox
fixanoid
Samer Falah
Nguyen Kien Trung
apratt3377
Joel Burget
Krish1979
Angela Pratt
chris-j-h
Sai V
libby kent
Peter Fox
Satpal
Qvintvs
Tomoaki Tsuzuki
SatpalSandhu61