consensys / quorum Goto Github PK

A permissioned implementation of Ethereum supporting data privacy

License: GNU Lesser General Public License v3.0

Makefile 0.08% Go 89.08% Shell 0.10% C 4.59% JavaScript 2.99% Ruby 0.01% M4 0.18% Java 0.21% Assembly 0.65% HTML 0.08% NSIS 0.16% Python 0.04% Dockerfile 0.01% Solidity 1.63% Sage 0.21%

blockchain ledger privacy ethereum consensus go protocols-team-goquorum goquorum quorum eea

quorum's Introduction

GoQuorum is an Ethereum-based distributed ledger protocol with transaction/contract privacy and new consensus mechanisms.

GoQuorum is a fork of go-ethereum and is updated in line with go-ethereum releases.

Key enhancements over go-ethereum:

Privacy - GoQuorum supports private transactions and private contracts through public/private state separation, and utilises peer-to-peer encrypted message exchanges (see Tessera) for directed transfer of private data to network participants
Alternative Consensus Mechanisms - with no need for POW/POS in a permissioned network, GoQuorum instead offers multiple consensus mechanisms that are more appropriate for consortium chains:
- QBFT - Improved version of IBFT that is interoperable with Hyperledger Besu
- Istanbul BFT - a PBFT-inspired consensus algorithm with transaction finality, by AMIS.
- Clique POA Consensus - a default POA consensus algorithm bundled with Go Ethereum.
- Raft-based Consensus - a consensus model for faster blocktimes, transaction finality, and on-demand block creation
Peer Permissioning - node/peer permissioning, ensuring only known parties can join the network
Account Management - GoQuorum introduced account plugins, which allows GoQuorum or clef to be extended with alternative methods of managing accounts including external vaults.
Pluggable Architecture - allows adding additional features as plugins to the core geth, providing extensibility, flexibility, and distinct isolation of GoQuorum features.
Higher Performance - GoQuorum offers significantly higher performance throughput than public geth

Architecture

The above diagram is very high-level overview of component architecture used by GoQuorum. For more in-depth discussion of the components and how they interact, please refer to lifecycle of a private transaction.

Quickstart

The easiest way to get started is to use * quorum-dev-quickstart - a command line tool that allows users to set up a development GoQuorum network on their local machine in less than 2 minutes.

GoQuorum Projects

Check out some of the interesting projects we are actively working on:

quorum-remix-plugin: The GoQuorum plugin for Ethereum's Remix IDE adds support for creating and interacting with private contracts on a GoQuorum network.
Cakeshop: An integrated development environment and SDK for GoQuorum
quorum-examples: GoQuorum demonstration examples
Quorum-Kubernetes: Deploy GoQuorum on Kubernetes
we3js-quorum: Extends web3.js to support GoQuorum and Hyperledger Besu specific APIs
Zero Knowledge on GoQuorum
- ZSL on GoQuorum
- Anonymous Zether

Official Docker Containers

The official docker containers can be found under https://hub.docker.com/u/quorumengineering/

Third Party Tools/Libraries

The following GoQuorum-related libraries/applications have been created by Third Parties and as such are not specifically endorsed by J.P. Morgan. A big thanks to the developers for improving the tooling around GoQuorum!

Chainlens Blockchain Explorer - a Blockchain Explorer for GoQuorum which supports viewing private transactions
Quorum-Genesis - A simple CL utility for GoQuorum to help populate the genesis file with voters and makers
Quorum Maker - a utility to create GoQuorum nodes
ERC20 REST service - a GoQuorum-supported RESTful service for creating and managing ERC-20 tokens
Nethereum Quorum - a .NET GoQuorum adapter
web3j-quorum - an extension to the web3j Java library providing support for the GoQuorum API
Apache Camel - an Apache Camel component providing support for the GoQuorum API using web3j library. Here is the article describing how to use Apache Camel with Ethereum and GoQuorum https://medium.com/@bibryam/enterprise-integration-for-ethereum-fa67a1577d43

Contributing

GoQuorum is built on open source and we invite you to contribute enhancements. Upon review you will be required to complete a Contributor License Agreement (CLA) before we are able to merge. If you have any questions about the contribution process, please feel free to send an email to [email protected]. Please see the Contributors guide for more information about the process.

Reporting Security Bugs

Security is part of our commitment to our users. At GoQuorum we have a close relationship with the security community, we understand the realm, and encourage security researchers to become part of our mission of building secure reliable software. This section explains how to submit security bugs, and what to expect in return.

All security bugs in GoQuorum and its ecosystem (Tessera, Cakeshop, ..etc) should be reported by email to [email protected]. Please use the prefix [security] in your subject. This email is delivered to GoQuorum security team. Your email will be acknowledged, and you'll receive a more detailed response to your email as soon as possible indicating the next steps in handling your report. After the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement.

If you have not received a reply to your email or you have not heard from the security team please contact any team member through GoQuorum slack security channel. Please note that GoQuorum discord channels are public discussion forum. When escalating to this medium, please do not disclose the details of the issue. Simply state that you're trying to reach a member of the security team.

Responsible Disclosure Process

GoQuorum project uses the following responsible disclosure process:

Once the security report is received it is assigned a primary handler. This person coordinates the fix and release process.
The issue is confirmed and a list of affected software is determined.
Code is audited to find any potential similar problems.
If it is determined, in consultation with the submitter, that a CVE-ID is required, the primary handler will trigger the process.
Fixes are applied to the public repository and a new release is issued.
On the date that the fixes are applied, announcements are sent to Quorum-announce.
At this point you would be able to disclose publicly your finding.

Note: This process can take some time. Every effort will be made to handle the security bug in as timely a manner as possible, however it's important that we follow the process described above to ensure that disclosures are handled consistently.

Receiving Security Updates

The best way to receive security announcements is to subscribe to the Quorum-announce mailing list/channel. Any messages pertaining to a security issue will be prefixed with [security].

Comments on This Policy If you have any suggestions to improve this policy, please send an email to [email protected] for discussion.

License

The go-ethereum library (i.e. all code outside of the cmd directory) is licensed under the GNU Lesser General Public License v3.0, also included in our repository in the COPYING.LESSER file.

The go-ethereum binaries (i.e. all code inside of the cmd directory) is licensed under the GNU General Public License v3.0, also included in our repository in the COPYING file.

Any project planning to use the crypto/secp256k1 sub-module must use the specific secp256k1 standalone library licensed under 3-clause BSD.

quorum's People

Contributors

Stargazers

Watchers

Forkers

chetan wanxiangblockchain hoardboard ggthedev microempathy payingattention malisetti alter-sachin sstelfox slietz kustomzone healtech saitop sergeyganago gcc2ge ia-sadosky jorv isghe penghuangcn ksinkar moneytrigz chunsj maniacs-ops josejamilena devopsbox joeb000 hemel-cse pjworrall mikedeshazer dadasoz orbro alexshpiller whycoding126 chandraprakash libertymutual vietthaotran dvisacker rm3l jcrain daoway mikesmo cigolabs melowe chatelcedric nbnayak88 yesppg shaguftarjpt673 gaurilab magooster sp1r00000 vanderheijden86 ethereumex davebryson skbodwell golang-kit victortaelin mavstronaut bas-vk etherai gsalgado duckhip ermyas bts feronti wepesa mlg-blockchain mayoricodevault obscuren smart-t codewinguagua 15921483570 gurghet loxadim sbepstein coeniebeyers gazbert cenwei codeaudit wowtoshi tniermann jacksoom 7sea colortigerhu harendranathvegi9 omgchain reyadrahman kevinzhu1994 vjrantal scottdonaldau n1zyz haiderny hermannity kishorebhatia kenken64 thebeast0407 dconroy emptybytes trust-tech smatthewenglish codiscope-public

quorum's Issues

Blockmaker account fails to unlock when missing 0x

System information

Geth version: 1.5.0-unstable

OS & Version: All

Branch : master

Expected behaviour

I should be able to unlock a blockmaker account if it doesn't start with 0x, similar to the voteraccount.

Actual behaviour

A fatal exception is thrown:

Fatal: Unable to unlock block maker key: account is locked

Steps to reproduce the behaviour

Pass a blockmaker address that doesn't start with 0x when starting quorum:

--blockmakeraccount "ca843569e3427144cead5e4d5999a3d0ccf92b8e"

There is no need to drop the first 2 values from the address when retrieving the key, if 0x is included, it will be handled in the hex to address coversion

blockVoteKey, err = accman.Key(common.HexToAddress(addr[2:]))

Allow sending a private transaction for (just) yourself

The function call will fail if privateFor is “” and does not work if privateFor is absent because I think it creates a public transaction calling a private contract.

How does block maker chooses transactions and put them in a block ?

In Ethereum world, the factors that decide which transaction will be added in a block depends upon when the transaction is submitted and its gas price. The transactions with higher gas price are picked first.
If the blocked is almost full then the lower price transaction can also be added into the bock.

In Quorum we have block maker and voter and there is no reward system or mining concept.
Can you please help understand how exactly it happens in Quorum.

Thanks
-Gourav

Observer node crash

System information

Geth version: geth version

Geth
Version: 1.5.0-unstable
Git Commit: 6d0bd810484f4c56f7c9aebc229e1bdc56832ced
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Windows/Linux/OSX
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-59-generic x86_64)

Branch, Commit Hash or Release: git status
HEAD detached at v1.0.2

Expected behaviour

Actual behaviour

I issued a private transaction between node A and B. My node C (observer) crashed and is not starting.
C does not have an associated constellation node. I assumed that observers would not require it. Could that be the issue ?

Steps to reproduce the behaviour

Backtrace

E0221 11:18:33.968268 core/quorum/block_voting.go:280] Unable to vote: Node is not configured for voting
I0221 11:18:38.974174 eth/downloader/downloader.go:326] Block synchronisation started
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x5239cd]

goroutine 190 [running]:
panic(0xc69640, 0xc42000e0a0)
	/usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/ethereum/go-ethereum/core.(*StateTransition).TransitionDb(0xc420e6b1f0, 0xc420cae100, 0x154d6a0, 0xc420e28900, 0xc42137f160, 0xc420e6b1f0, 0xc420cae100, 0xc421428ae0)
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/state_transition.go:241 +0xe4d
github.com/ethereum/go-ethereum/core.ApplyMessage(0x154ff60, 0xc420cae100, 0x154d6a0, 0xc420e28900, 0xc42137f160, 0xc420e28900, 0xc421384480, 0x76b6acecad000000, 0x0, 0x0, ...)
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/state_transition.go:144 +0x65
github.com/ethereum/go-ethereum/core.ApplyTransaction(0xc4200864e0, 0xc4203eb7a0, 0xc42137f160, 0xc4201474a0, 0xc420147c20, 0xc421384480, 0xc420e28900, 0xc42137f0a0, 0x0, 0x0, ...)
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/state_processor.go:96 +0x385
github.com/ethereum/go-ethereum/core.(*StateProcessor).Process(0xc4201b6d80, 0xc420e24ab0, 0xc4201474a0, 0xc420147c20, 0x21b463e3b5000000, 0x0, 0x0, 0x6ef8c092e64583ff, 0xc0ad6c991be0485b, 0x21b463e3b52f6201, ...)
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/state_processor.go:70 +0x3f0
github.com/ethereum/go-ethereum/core.(*BlockChain).InsertChain(0xc4203eb7a0, 0xc4212cc000, 0x6, 0x800, 0x0, 0x0, 0x0)
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/blockchain.go:934 +0xfe1
github.com/ethereum/go-ethereum/eth.(*ProtocolManager).insertChain(0xc420060a90, 0xc4212cc000, 0x6, 0x800, 0x160bf20, 0xc420cdbde0, 0xc4212ded80)
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/handler.go:176 +0x51
github.com/ethereum/go-ethereum/eth.(*ProtocolManager).(github.com/ethereum/go-ethereum/eth.insertChain)-fm(0xc4212cc000, 0x6, 0x800, 0x4, 0x160bf20, 0x0)
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/handler.go:152 +0x48
github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).processContent(0xc42013a540, 0xf37078, 0xc420e2b010)
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/downloader/downloader.go:1379 +0xe2b
github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).spawnSync.func1(0xc420e2b010, 0xc420e5b920, 0xc42013a540)
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/downloader/downloader.go:462 +0x57
created by github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).spawnSync
	/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/downloader/downloader.go:462 +0xce

Inconsistent Voting behaviour

According to the Consensus section of the document, voter nodes will vote when they receive a newly generated block via the standard Ethereum P2P protocol (ChainHeadEvent). However they also appear to vote on the block generation event (CreateBlock).

E0120 21:44:49.886387 core/quorum/block_voting.go:288] Unable to create block: Node not configured for block creation
I0120 21:44:49.886915 core/quorum/block_voting.go:388] vote for 0xbb889fee70776551d79d7d65f6b5c3b1c932e15f63e3dba40b95b071e
495cab5 on height 8

As all nodes run the BlockMakerStrategy, looking in core/quorum/block_voting.go, in the run function for the CreateBlock event case it would seem that any voter node that is not enabled for block creation (i.e. createBlock will fail) will then always attempt to vote for the hash of the parent block of its current pending state.

Unable to vote: Node is not configured for voting

Hi,

I am getting the following error when running my node. I am building my own setup by mimicking the 7nodes examples : E0213 11:20:55.824797 core/quorum/block_voting.go:280] Unable to vote: Node is not configured for voting

ubuntu@ubuntu-xenial:~/slibquorum$ ./start.sh 
[*] Starting Constellation nodes
wait for constellation to start...
I0213 11:20:48.249306 ethdb/database.go:81] Allotted 128MB cache and 1024 file handles to /home/ubuntu/slibquorum/qdata/dd1/geth/chaindata
I0213 11:20:48.255484 ethdb/database.go:174] closed db:/home/ubuntu/slibquorum/qdata/dd1/geth/chaindata
I0213 11:20:48.256019 node/node.go:177] instance: Geth/v1.5.0-unstable-6d0bd810/linux/go1.7.3
I0213 11:20:48.256071 ethdb/database.go:81] Allotted 128MB cache and 1024 file handles to /home/ubuntu/slibquorum/qdata/dd1/geth/chaindata
I0213 11:20:48.258845 eth/db_upgrade.go:346] upgrading db log bloom bins
I0213 11:20:48.259091 eth/db_upgrade.go:354] upgrade completed in 248.437µs
I0213 11:20:48.259574 eth/backend.go:175] Protocol Versions: [63 62], Network Id: 87234
I0213 11:20:48.260240 core/blockchain.go:221] Last header: #0 [c693d893…] TD=0
I0213 11:20:48.260284 core/blockchain.go:222] Last block: #0 [c693d893…] TD=0
I0213 11:20:48.260295 core/blockchain.go:223] Fast block: #0 [c693d893…] TD=0
I0213 11:20:48.261062 p2p/server.go:328] Starting Server
I0213 11:20:50.367222 p2p/discover/udp.go:217] Listening, enode://57899d00957cac37e677ceee49733512a33afef75766b55db1e3ff44a4dfc0f14a71ad6caf627735b3ecd767c8cafefd8ce0b7669abcc28c7c1b1f5f462c14db@[::]:21000
I0213 11:20:50.369329 node/node.go:412] HTTP endpoint opened: http://0.0.0.0:22000
I0213 11:20:50.369501 p2p/server.go:582] Listening on [::]:21000
I0213 11:20:50.369631 node/node.go:342] IPC endpoint opened: /home/ubuntu/slibquorum/qdata/dd1/geth.ipc
I0213 11:20:50.823090 cmd/geth/accountcmd.go:189] Unlocked account d7337738035b12f14e44a5d9b3dae275ccce390b
E0213 11:20:55.824797 core/quorum/block_voting.go:280] Unable to vote: Node is not configured for voting

Below is the genesis.json that I generated to match this setup

voteThreshold:  1
4 Voters : 
#0 Voter Address: 0xd7337738035b12f14e44a5d9b3dae275ccce390b
#1 Voter Address: 0x5622435f5d2ae1e6ac1792a1ce52cf90430da53b
#2 Voter Address: 0x80d8b4f047bcc56b36c194aa1de707ce1944c25f
#3 Voter Address: 0x958f3f2bcaf22b090103f72b0a64dc2c79dca329

2 Block Makers
#0 Block Maker Address: 0xd7337738035b12f14e44a5d9b3dae275ccce390b
#1 Block Maker Address: 0xc39cfc95f606d7dd9b6f2710a243a16e6ae3d492


{
    "alloc": {
        "0x0000000000000000000000000000000000000020": {
            "code": "606060 ..... 00360200190a16100f656",
            "storage": {
                "0x0000000000000000000000000000000000000000000000000000000000000001": "0x01",
                "0x0000000000000000000000000000000000000000000000000000000000000002": "0x04",
                "0xc57d32e96a0c5aaf699b1629a9bd56d03eca36d1e29ef7ab39b06c4168837750": "0x01",
                "0x0cda27081755ec676dc437da73afc7edf00e36a65af56254aff09620128d8f03": "0x01",
                "0xe0a1928612751260079a79c6cc47d5b19913f9dfc6c334b0f35ab517c950340c": "0x01",
                "0xcf5c9ed23cdc0211fc6b6807ef3088bbd8ea43399a94b7b54bb477e1bc7cdb41": "0x01",
                "0x0000000000000000000000000000000000000000000000000000000000000004": "0x02",
                "0xe0c3bd5b9e5f66526dcd0d515da030f4b25a74ff0105db9e4a756920f7f5f840": "0x01",
                "0x7c373f092f893671c3c920e2cfd32b9c94aa0f8359b7ea4699c6a6d10e15d1c6": "0x01"
            }
        },
        "0xd7337738035b12f14e44a5d9b3dae275ccce390b": {
            "balance": "1000000000000000000000000000"
        },
        "0x5622435f5d2ae1e6ac1792a1ce52cf90430da53b": {
            "balance": "1000000000000000000000000000"
        },
        "0x80d8b4f047bcc56b36c194aa1de707ce1944c25f": {
            "balance": "1000000000000000000000000000"
        },
        "0x958f3f2bcaf22b090103f72b0a64dc2c79dca329": {
            "balance": "1000000000000000000000000000"
        },
        "0xc39cfc95f606d7dd9b6f2710a243a16e6ae3d492": {
            "balance": "1000000000000000000000000000"
        }
    },
    "coinbase": "0xd7337738035b12f14e44a5d9b3dae275ccce390b",
    "config": {
        "homesteadBlock": 0
    },
    "difficulty": "0x0",
    "extraData": "0x",
    "gasLimit": "0x2FEFD800",
    "mixhash": "0x00000000000000000000000000000000000000647572616c65787365646c6578",
    "nonce": "0x0",
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "timestamp": "0x00"
}

ethclient: "invalid hex log data" when using FilterLogs

ethereum/go-ethereum#3328

Also affects Quorum. Geth fixed it, could we cat a backport? Thanks

How is the Storage map populated in the genesis.json?

System information

Geth version: geth version
OS & Version: Linux Ubuntu

Expected behaviour

PRIVATE_CONFIG=tm1.conf nohup geth --datadir qdata/issuer1 $GLOBAL_ARGS --rpcport 22000 --port 21000 --unlock "0x93546f0314bf8eacb3ea45ba75dfcd1a2341e59b" --voteaccount "0x8a19fcbf7150d5ede014fd706ff246176a2c85fa" --votepassword "" --password passwords.txt 2>>qdata/logs/1.log &

should assign voting privileges to 0x8a19..59b

Actual behaviour

E1221 20:00:04.904205 core/quorum/block_voting.go:280] Unable to vote: 0x8a19fcbf7150d5ede014fd706ff246176a2c85fa is not allowed to vote

Is the solution to this in populating the storage map? If so, how is the storage key:value pairs calculated?
What is the <256 bit variable index> mentioned in https://github.com/jpmorganchase/quorum/blob/master/docs/running.md

A maker who is also a voter can vote twice for a block

System information

Geth version: geth version

Geth
Version: 1.5.0-unstable
Git Commit: 85327f7
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Windows/Linux/OSX
Linux ubuntu-xenial 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Branch, Commit Hash or Release: git status
q1.0.1

Expected behaviour

A maker who is also a voter should only vote once for a particular block.

Actual behaviour

The maker nodes can vote twice, once when creating a block and again when a ChainHeadEvent occurs.

Steps to reproduce the behaviour

Using the 7-node example - with no other transactions the maker node will have generated twice as many vote transactions as the two other voting nodes.

See: block_voting.go case core.ChainHeadEvent and case CreateBlock.

Backtrace

[backtrace]

bootnode & geth not starting

Hi,

Running geth or bootnode is not doing anything. No error message, no outpout. the command just returns . I am working off the 7 nodes examples

ubuntu@ubuntu-xenial:~/quorum$ git status 
HEAD detached at v1.0.2

Getting 'Failed to start Ledger hub, disabling: libusb: unknown error [code -99]' while running init.sh

System information

Geth version: 1.5.9-stable

OS & Version: OSX

Branch, Commit Hash or Release: git status

Expected behaviour

[] Cleaning up temporary data directories
[] Configuring node 1
[] Configuring node 2 as block maker and voter
[] Configuring node 3
[] Configuring node 4 as voter
[] Configuring node 5 as voter
[] Configuring node 6
[] Configuring node 7

Actual behaviour

[] Cleaning up temporary data directories
[] Configuring node 1
I0308 12:40:47.339045 node/config.go:445] Failed to start Ledger hub, disabling: libusb: unknown error [code -99]
I0308 12:40:47.342796 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd1/geth/chaindata
I0308 12:40:47.364423 ethdb/database.go:176] closed db:/vagrant/examples/7nodes/qdata/dd1/geth/chaindata
I0308 12:40:47.365311 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd1/geth/chaindata
I0308 12:40:47.399633 cmd/geth/chaincmd.go:132] successfully wrote genesis block and/or chain rule set: 8bb911238205c6d5e9841335c9c5aff3dfae4c0f6b0df28100737c2660a15f8d
[] Configuring node 2 as block maker and voter
I0308 12:40:47.467341 node/config.go:445] Failed to start Ledger hub, disabling: libusb: unknown error [code -99]
I0308 12:40:47.471886 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd2/geth/chaindata
I0308 12:40:47.494898 ethdb/database.go:176] closed db:/vagrant/examples/7nodes/qdata/dd2/geth/chaindata
I0308 12:40:47.495900 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd2/geth/chaindata
I0308 12:40:47.531871 cmd/geth/chaincmd.go:132] successfully wrote genesis block and/or chain rule set: 8bb911238205c6d5e9841335c9c5aff3dfae4c0f6b0df28100737c2660a15f8d
[] Configuring node 3
I0308 12:40:47.588897 node/config.go:445] Failed to start Ledger hub, disabling: libusb: unknown error [code -99]
I0308 12:40:47.591326 cmd/utils/flags.go:613] WARNING: No etherbase set and no accounts found as default
I0308 12:40:47.592437 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd3/geth/chaindata
I0308 12:40:47.611397 ethdb/database.go:176] closed db:/vagrant/examples/7nodes/qdata/dd3/geth/chaindata
I0308 12:40:47.612307 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd3/geth/chaindata
I0308 12:40:47.653402 cmd/geth/chaincmd.go:132] successfully wrote genesis block and/or chain rule set: 8bb911238205c6d5e9841335c9c5aff3dfae4c0f6b0df28100737c2660a15f8d
[] Configuring node 4 as voter
I0308 12:40:47.718636 node/config.go:445] Failed to start Ledger hub, disabling: libusb: unknown error [code -99]
I0308 12:40:47.722003 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd4/geth/chaindata
I0308 12:40:47.743173 ethdb/database.go:176] closed db:/vagrant/examples/7nodes/qdata/dd4/geth/chaindata
I0308 12:40:47.743996 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd4/geth/chaindata
I0308 12:40:47.776097 cmd/geth/chaincmd.go:132] successfully wrote genesis block and/or chain rule set: 8bb911238205c6d5e9841335c9c5aff3dfae4c0f6b0df28100737c2660a15f8d
[] Configuring node 5 as voter
I0308 12:40:47.842876 node/config.go:445] Failed to start Ledger hub, disabling: libusb: unknown error [code -99]
I0308 12:40:47.844185 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd5/geth/chaindata
I0308 12:40:47.865765 ethdb/database.go:176] closed db:/vagrant/examples/7nodes/qdata/dd5/geth/chaindata
I0308 12:40:47.867094 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd5/geth/chaindata
I0308 12:40:47.902816 cmd/geth/chaincmd.go:132] successfully wrote genesis block and/or chain rule set: 8bb911238205c6d5e9841335c9c5aff3dfae4c0f6b0df28100737c2660a15f8d
[] Configuring node 6
I0308 12:40:47.961862 node/config.go:445] Failed to start Ledger hub, disabling: libusb: unknown error [code -99]
I0308 12:40:47.964061 cmd/utils/flags.go:613] WARNING: No etherbase set and no accounts found as default
I0308 12:40:47.965102 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd6/geth/chaindata
I0308 12:40:47.990171 ethdb/database.go:176] closed db:/vagrant/examples/7nodes/qdata/dd6/geth/chaindata
I0308 12:40:47.991111 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd6/geth/chaindata
I0308 12:40:48.032121 cmd/geth/chaincmd.go:132] successfully wrote genesis block and/or chain rule set: 8bb911238205c6d5e9841335c9c5aff3dfae4c0f6b0df28100737c2660a15f8d
[] Configuring node 7
I0308 12:40:48.088544 node/config.go:445] Failed to start Ledger hub, disabling: libusb: unknown error [code -99]
I0308 12:40:48.090904 cmd/utils/flags.go:613] WARNING: No etherbase set and no accounts found as default
I0308 12:40:48.092105 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd7/geth/chaindata
I0308 12:40:48.112309 ethdb/database.go:176] closed db:/vagrant/examples/7nodes/qdata/dd7/geth/chaindata
I0308 12:40:48.113170 ethdb/database.go:83] Allotted 128MB cache and 1024 file handles to /vagrant/examples/7nodes/qdata/dd7/geth/chaindata
I0308 12:40:48.148037 cmd/geth/chaincmd.go:132] successfully wrote genesis block and/or chain rule set: 8bb911238205c6d5e9841335c9c5aff3dfae4c0f6b0df28100737c2660a15f8d

Steps to reproduce the behaviour

By running init.sh

Backtrace

[backtrace]

Makefile fails to build the project with Go 1.8

System information

Geth version: geth version
Version: 1.5.9-stable
Git Commit: a07539f
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/lib/go-1.7

OS & Version: Windows/Linux/OSX
Ubuntu 14.04

Branch, Commit Hash or Release: git status
On branch master, commit e6282c2

Update:
$go version
go version go1.8 linux/amd64

Expected behaviour

git clone https://github.com/jpmorganchase/quorum.git
cd quorum
make all
make test

Actual behaviour

git clone https://github.com/jpmorganchase/quorum.git
cd quorum
make all
build/env.sh go run build/ci.go install
unexpected directory layout:
import path: _/home/coenie/workspace/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/internal/build
root: /home/coenie/workspace/quorum/build/_workspace/src
dir: /home/coenie/workspace/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/internal/build
expand root: /home/coenie/workspace/quorum/build/_workspace/src
expand dir: /home/coenie/workspace/quorum/internal/build
separator: /
make: *** [all] Error 1

Steps to reproduce the behaviour

make all

Backtrace

[backtrace]

Gas and Transactions

It appears that no gas is consumed for transactions (gasPrice = 0). Is this correct? Yet you need a funded account to send transactions. Which means if I don't transfer value, I can make as many transaction calls as I like because gas will never reduce my balance.

Will the use of gas or account balance change in future versions of Quorum or is this the intended design?

quorum-examples/7nodes/start.sh may send transaction through node that has yet to come up fully

System information

Geth version: 1.5.0-unstable
OS & Version: Quickstart environment using Vagrant 1.7.4 on OS X Sierra
Commit hash : (if develop)

Expected behaviour

Node runs.

Actual behaviour

Node died.

Steps to reproduce the behaviour

I've not been able to reproduce the issue - the node subsequently started when I ran it manually. However, when I ran start.sh first time around while following the instructions on the Quorum quickstart, the first geth node fell over after starting. The log is below.

Backtrace

I1201 04:39:25.712308 ethdb/database.go:81] Allotted 128MB cache and 1024 file handles to /home/ubuntu/quorum-examples/7nodes/qdata/dd1/geth/chaindata
I1201 04:39:25.745917 ethdb/database.go:174] closed db:/home/ubuntu/quorum-examples/7nodes/qdata/dd1/geth/chaindata
I1201 04:39:25.746230 node/node.go:177] instance: Geth/v1.5.0-unstable-85327f74/linux/go1.7.3
I1201 04:39:25.746247 ethdb/database.go:81] Allotted 128MB cache and 1024 file handles to /home/ubuntu/quorum-examples/7nodes/qdata/dd1/geth/chaindata
I1201 04:39:26.615043 eth/db_upgrade.go:346] upgrading db log bloom bins
I1201 04:39:26.615161 eth/db_upgrade.go:354] upgrade completed in 121.438µs
I1201 04:39:26.615191 eth/backend.go:175] Protocol Versions: [63 62], Network Id: 87234
I1201 04:39:26.615627 core/blockchain.go:221] Last header: #0 [8bb91123…] TD=0
I1201 04:39:26.615644 core/blockchain.go:222] Last block: #0 [8bb91123…] TD=0
I1201 04:39:26.615653 core/blockchain.go:223] Fast block: #0 [8bb91123…] TD=0
I1201 04:39:26.616186 p2p/server.go:328] Starting Server
I1201 04:39:28.784700 p2p/discover/udp.go:217] Listening, enode://17cd61af0a5a9ae2b93fdf429502dde22476052c8ecd77de638ae33bc74c254a46b22a7247bb9d85f88381dd2f1dac684ee43b5e242c757f0deff2cc3fba55de@[::]:21000
I1201 04:39:28.788913 node/node.go:412] HTTP endpoint opened: http://localhost:22000
I1201 04:39:30.860670 p2p/server.go:582] Listening on [::]:21000
I1201 04:39:30.860941 node/node.go:342] IPC endpoint opened: /home/ubuntu/quorum-examples/7nodes/qdata/dd1/geth.ipc
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x534e12]

goroutine 84 [running]:
panic(0xc672a0, 0xc420012090)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/ethereum/go-ethereum/core/state.(*ManagedState).GetNonce(0x0, 0x1848b382e3029ded, 0x71fec709a3888be8, 0x9d415fe6, 0x0)
        /home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/state/managed_state.go:87 +0x32
github.com/ethereum/go-ethereum/eth.(*EthApiBackend).GetPoolNonce(0xc4200de580, 0x7f8915388980, 0xc4201c7ec0, 0x1848b382e3029ded, 0x71fec709a3888be8, 0x9d415fe6, 0x0, 0x0, 0x0)
        /home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/api_backend.go:153 +0xb9
github.com/ethereum/go-ethereum/internal/ethapi.(*PublicTransactionPoolAPI).SendTransaction(0xc4201ce200, 0x7f8915388980, 0xc4201c7ec0, 0x1848b382e3029ded, 0x71fec709a3888be8, 0x9d415fe6, 0x0, 0xc4200db9c0, 0xc4200dbae0, 0xc4200dbdc0, ...)
        /home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/internal/ethapi/api.go:1076 +0xfd7
reflect.Value.call(0xc42014fc80, 0xc4200ded88, 0x13, 0xd4b09d, 0x4, 0xc4203e55c0, 0x3, 0x4, 0x0, 0xca5c40, ...)
        /usr/local/go/src/reflect/value.go:434 +0x5c8
reflect.Value.Call(0xc42014fc80, 0xc4200ded88, 0x13, 0xc4203e55c0, 0x3, 0x4, 0x1, 0x1, 0x0)
        /usr/local/go/src/reflect/value.go:302 +0xa4
github.com/ethereum/go-ethereum/rpc.(*Server).handle(0xc42028cf30, 0x7f8915388980, 0xc4201c7ec0, 0x154a720, 0xc42008f220, 0xc42026c700, 0x0, 0x0, 0x0)
        /home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/rpc/server.go:318 +0x8ed
github.com/ethereum/go-ethereum/rpc.(*Server).exec(0xc42028cf30, 0x7f8915388980, 0xc4201c7ec0, 0x154a720, 0xc42008f220, 0xc42026c700)
        /home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/rpc/server.go:340 +0x1e4
created by github.com/ethereum/go-ethereum/rpc.(*Server).serveRequest
        /home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/rpc/server.go:213 +0x371

Clarification blockmaker node

Hi,

Please can you clarify if all transactions API calls should be sent to blockmaker nodes ?

I find that when sending to non-blockmaker nodes, transactions are not being processed. I would like to know if this the expected behaviour or if something is wrong with my setup .

Thank you

Private Transactions failure

System information

Geth version: geth version

Geth
Version: 1.5.0-unstable
Git Commit: 6d0bd810484f4c56f7c9aebc229e1bdc56832ced
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Windows/Linux/OSX
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-59-generic x86_64)

Branch, Commit Hash or Release: git status
HEAD detached at v1.0.2

Expected behaviour

transaction should be processed

Actual behaviour

failure. see error below

Steps to reproduce the behaviour

sending a private transaction or contract

Backtrace

[Error: Non-200 status code: &{Status:500 Internal Server Error StatusCode:500 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Date:[Mon, 20 Feb 2017 16:10:29 GMT] Server:[Warp/3.2.8]] Body:0xc425270600 ContentLength:-1 TransferEncoding:[chunked] Close:false Uncompressed:false Trailer:map[] Request:0xc421a5e3c0 TLS:<nil>}]

Can't create contract

Hi,
Is there a way to check why my contract creation is not happening ?
This is what I get in the node logs

I0214 13:17:24.973787 internal/ethapi/api.go:1196] Tx(0xb26b50ed3454338f9245bbfac35c44b5293393dd51f8435cb7b530ee6fdddb0f) created: 0x573723618e03ab2d9e6dc3a445894603163cb81c
But when I query the Tx:

>eth.getTransaction("0xb26b50ed3454338f9245bbfac35c44b5293393dd51f8435cb7b530ee6fdddb0f")
null

I wonder if the node I am initiating the transaction from need to be a blockmaker node? Does it mean that no transaction should be created from observer nodes ?

I noticed that even simple transactions (eth transfer between account) don't work from this node.

Thanks

Panic when deploying new contract

I have an automated test which starts a single quorum node, with a single account, a pristine chain and configured as a voter and block maker. My test them uses that account to deploy a new contract, but that causes geth to panic with the following trace:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x55eb1d6c4440]

goroutine 48 [running]:
panic(0x55eb1dd88320, 0xc420018100)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/ethereum/go-ethereum/eth.(*EthApiBackend).GetVMEnv(0xc4200346f0, 0x7f57d016f398, 0xc4201f2750, 0x55eb1e671740, 0xc4204333b0, 0x55eb1e66e320, 0xc420019040, 0xc42026ed80, 0x9, 0xc42043f690, ...)
        /home/salgado/goprojects/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/api_backend.go:105 +0xc0
github.com/ethereum/go-ethereum/internal/ethapi.(*PublicBlockChainAPI).doCall(0xc4201e5070, 0x7f57d016f398, 0xc4201f2750, 0x9b5b1ce56bae12eb, 0x5e1454c835d5ab90, 0x777b133d, 0x0, 0x0, 0x0, 0x0, ...)
        /home/salgado/goprojects/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/internal/ethapi/api.go:703 +0x429
github.com/ethereum/go-ethereum/internal/ethapi.(*PublicBlockChainAPI).EstimateGas(0xc4201e5070, 0x7f57d016f398, 0xc4201f2750, 0x9b5b1ce56bae12eb, 0x5e1454c835d5ab90, 0x777b133d, 0x0, 0x0, 0x0, 0x0, ...)
        /home/salgado/goprojects/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/internal/ethapi/api.go:727 +0x86
reflect.Value.call(0xc420102f00, 0xc4200352d8, 0x13, 0x55eb1de6c3bd, 0x4, 0xc4200b6c60, 0x3, 0x4, 0x0, 0x55eb1ddc6ea0, ...)
        /usr/local/go/src/reflect/value.go:434 +0x5c8
reflect.Value.Call(0xc420102f00, 0xc4200352d8, 0x13, 0xc4200b6c60, 0x3, 0x4, 0x1, 0x1, 0x0)
        /usr/local/go/src/reflect/value.go:302 +0xa4
github.com/ethereum/go-ethereum/rpc.(*Server).handle(0xc420453b30, 0x7f57d016f398, 0xc4201f2750, 0x55eb1e671540, 0xc4204504b0, 0xc4202b6540, 0x0, 0x0, 0x0)
        /home/salgado/goprojects/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/rpc/server.go:318 +0x8ed
github.com/ethereum/go-ethereum/rpc.(*Server).exec(0xc420453b30, 0x7f57d016f398, 0xc4201f2750, 0x55eb1e671540, 0xc4204504b0, 0xc4202b6540)
        /home/salgado/goprojects/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/rpc/server.go:340 +0x1e4
created by github.com/ethereum/go-ethereum/rpc.(*Server).serveRequest
        /home/salgado/goprojects/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/rpc/server.go:213 +0x371

The panic is caused because GetVMEnv tries to dereference msg.To(), but IIUC that will always be nil for a message that creates a new contract, no?

Logs aren't currently visible in private transactions

I have got our Ethereum smart contracts up and running in Quorum and can interact with them in a limited way using the Mist wallet. Am I right in that events won't work if the contracts are marked as private? If that is the case will events be added in the future assuming that even makes sense to do so?

Vote transactions continue to be sent when block-making is paused

I am running a 5 node cluster (followed instructions here for the most part). When I paused the Block Maker, I noticed a ton of transactions stacking up in the txpool. Here is the output of txpool.inspect.pending:

> txpool.inspect.pending
{
  0x0638e1574728b6d862dd5d3a3e0942c3be47d996: {
    0: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    1: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    10: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    11: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    12: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    13: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    14: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    15: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    16: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    17: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    18: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    19: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    2: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    20: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    21: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    22: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    23: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    24: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    25: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    26: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    27: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    28: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    29: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    3: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    30: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    31: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    32: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    33: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    34: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    35: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    36: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    37: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    38: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    39: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    4: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    40: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    41: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    42: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    43: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    44: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    45: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    46: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    47: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    48: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    49: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    5: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    50: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    51: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    52: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    53: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    54: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    55: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    56: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    57: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    58: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    59: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    6: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    60: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    61: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    62: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    63: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    64: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    65: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    66: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    7: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    8: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    9: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas"
  },
  0x0fbdc686b912d7722dc86510934589e0aaf3b55a: {
    0: "0x0000000000000000000000000000000000000020: 0 wei + 91996 × 0 gas"
  },
  0x9186eb3d20cbd1f5f992a950d808c4495153abd5: {
    0: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    1: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    10: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    11: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    12: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    13: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    14: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    15: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    16: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    17: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    18: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    19: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    2: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    20: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    21: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    22: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    23: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    24: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    25: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    26: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    27: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    28: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    29: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    3: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    30: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    31: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    32: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    33: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    34: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    35: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    36: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    37: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    38: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    39: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    4: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    40: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    41: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    42: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    43: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    44: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    45: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    46: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    47: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    48: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    49: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    5: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    50: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    51: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    52: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    53: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    54: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    55: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    56: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    57: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    58: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    59: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    6: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    60: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    61: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    62: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    63: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    64: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    65: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    66: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    67: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    68: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    69: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    7: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    70: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    71: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    72: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    8: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas",
    9: "0x0000000000000000000000000000000000000020: 0 wei + 31355 × 0 gas"
  }
}

Blockmaker isn't allowed to create blocks

I am trying to start custom Quorum blockchain nodes. I am referring 7-nodes example for the required commands. 7-nodes example is working fine.

While starting Block Maker + Voter Node using below commands I am getting “Invalid header: block-maker-address isn't allowed to create blocks” error.
Commands:

Ubuntu Terminal 1:
a. geth --datadir chain-data/blockmaker1 init genesis.json
b. bootnode --nodekeyhex "2f64c911455fd7a835531ad223f1212908b2760de8bfc9228f1329920a0bf887" --addr="127.0.0.1:33445"
Ubuntu Terminal 2:
a. GLOBAL_ARGS="--keystore /home/ashish/.ethereum/keystore --bootnodes enode://e6993a52aba890b93fcc0f7a1acae2457a6157212928fbf266ca55810d25b262115bfe36728e8d5866a64b7467083cd90f303bb16831ca6496b3e59d60cd13d5@127.0.0.1:33445 --rpc --rpcaddr 0.0.0.0 --rpcapi admin,db,eth,debug,miner,net,shh,txpool,personal,web3,quorum"
b. geth --datadir chain-data/blockmaker1 $GLOBAL_ARGS --rpcport 22001 --port 21001 --blockmakeraccount "0xa0baf8633c30657662d2835652d954c63373bbd3" --blockmakerpassword "123" --singleblockmaker --voteaccount "0x122424aef8ce2935b1f462b43fe3916490ce6446" --votepassword "123"
In Terminal 2 I am seeing below error.
Error:
E0331 11:35:10.250046 core/blockchain.go:1230] Bad block #1 (0x6118be867ebb0b675fb55f32d2ad0e2d137765c43a27e502df41d505abe7ff21)
E0331 11:35:10.250377 core/blockchain.go:1231] Invalid header: 0xa0baf8633c30657662d2835652d954c63373bbd3 isn't allowed to create blocks

I calculated Block Maker Hex value using below command and added it in genesis.json file under Storage index: “0x0000000000000000000000000000000000000000000000000000000000000004”.
Please find attached genesis file for reference.
key = "000000000000000000000000a0baf8633c30657662d2835652d954c63373bbd3" + "0000000000000000000000000000000000000000000000000000000000000003"
"000000000000000000000000a0baf8633c30657662d2835652d954c63373bbd30000000000000000000000000000000000000000000000000000000000000003"
web3.sha3(key, {"encoding": "hex"})
Output: "0x6b47c8152d2cea470622edd1a530f45709bb497e9ea9b28184a7b70920936878"

Please let me know if I am missing any step here.

genesis.txt

Quorum doesn't pick nodes from `static-nodes.json`

System information

Geth version: geth version
Version: 1.5.0-unstable

OS & Version: Windows/Linux/OSX
Linux: Ubuntu 16.04.2 LTS

Branch, Commit Hash or Release: git status
master
Git Commit: 6d0bd81

Expected behaviour

When <datadir>-static-nodes.json is present, geth should try to connect to those nodes.

Actual behaviour

Geth 1.5 does not try to connect to <datadir>-static-nodes.jsonas result of a bug. Here is issue on Go-Ethereum which is fixed in the later versions.

Rebasing with Go-Ethereum should fix this problem, but I'm not expecting this rebase to happen anytime soon. I just thought of opening this issue so people wont waste their time.

Why do you use a voting system instead of Tendermint or BFT?

I want to know why you decided to implement your own voting system instead of Terdermint for Ethereum.

Private contract accessing public variables on public contract aborts execution

Consider the following scenario:
ContractA is PUBLIC
ContractB is PRIVATE

contract ContractA {
mapping (bytes32 => bool) public contractAmapping;
}


contract ContractB {
mapping (bytes32 => bool) public contractBmapping;

function test(bytes32 _mappingID)  {
        ContractA contractAobject = ContractA(contractAaddress);
=>    contractBmapping[_mappingID] = contractAobject.contractAmapping(_mappingID); 
       (code continues....)
}
}

I have the following issue: When I remove the line with an arrow where contractB reads contractA´s mapping, everything works and the (code continues...) executes . If the line with an arrow is present, (code continues...) never executes.
AFAIK, my private contract is not making a state change in the public contract, it is only reading a variable on a read only VM, like this:
S -> (A) -> [B]
I tried to encapsulate the mapping with a getter function and got the same behavior.

Block Creation Strategy inconsistent with documentation

System information

Geth version: geth version
Geth
Version: 1.5.0-unstable
Git Commit: 85327f7
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Windows/Linux/OSX
Linux ubuntu-xenial 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Branch, Commit Hash or Release: git status
q1.0.1

Expected behaviour

From the Wiki,

each Maker generates a random duration (a timeout) that it has to wait before it can create a block

If a Maker reaches its timeout before any other Maker does it will create a block, after which it will generate a new random timeout for itself and wait for that to elapse before attempting to create another block.

Note that once a Maker begins the block creation process, the other Maker Nodes will reset their current timeout, generate a new random timeout, and wait until that expires before attempting to creating a block.

Actual behaviour

There is no random seed to the random function, so the random number sequence is deterministic.

The Maker timeout is actually reset twice - once when it starts creating a block and again when it inserts the newly created block onto its canonical chain.

The other Maker nodes timeout is only reset after a ChainHeadEvent, that is after the node has inserted a new block onto its canonical chain.

Steps to reproduce the behaviour

N/A - Code Review

Backtrace

[backtrace]

BlockVoting contract Vote event outputs current block.number not height voted for

In the vote function of the BlockVoting contract, the Vote event includes the block number when the vote was recorded.

Vote(msg.sender, block.number, hash);

Shouldn't the Vote event actually include the block height and hash voted for.

Vote(msg.sender, height, hash);

Private Transaction from Private Contract

System information

Geth version: geth version
1.5.0-unstable

OS & Version: Windows/Linux/OSX
Ubuntu 16.04.1 LTS

Branch, Commit Hash or Release: git status
Master

Expected behaviour

Should succeed

Actual behaviour

Transaction not getting deployed.

Steps to reproduce the behaviour

I have 6 Nodes each node having two accounts and are configured as Voter & Block maker.
I am trying to deploy contract(SimpleCustomerFactory) from node 6 as private to Node 1,2,3,4,5. It is getting deployed successfully.

Now I am trying to perform a private transaction(addCustomer) from the contract from node 6 to node 1.. I do receive transactionHash as a result, but I don't see the transaction to be added. Contract address remains null when I do getTransactionReceipt().
I don't see any error in any of the logs.
In the Node 6 log, I do see one line for the matching transaction hash.

I0318 09:24:48.615015 internal/ethapi/api.go:1060] Tx(0xcf39e4877e57e5f6e819832e
a9afbb3a863fb0f77d156147ab2933177bb09125) to: 0x6a8331ace0824d4c7872f6d2618b45a4
2f887798

I have attached the contract code and configuration files for your reference

init.txt
start.txt
SimpleCustomerFactory.txt
SimpleCustomer.txt

y i cant mine it ???

i try mine it for early bird gold mine dump and it dont work ???

Voter nodes won't vote unless chain sync has occured

In the setup of a new chain voter nodes wont vote unless a chain sync occurs.

System information

Geth version: geth version
Geth
Version: 1.5.0-unstable
Git Commit: 85327f7
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Windows/Linux/OSX
Linux ubuntu-xenial 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Branch, Commit Hash or Release: git status
q1.0.1

Expected behaviour

Voter node should vote for a block, when a ChainHeadEvent occurs in response to importing a new block provided they have synchronised with the chain (downloader.DoneEvent).

Actual behaviour

Voter nodes that are part of the initial chain never undertake a chain synchronisation, as by definition they are already in sync. They do still vote but only when a createBlock event occurs as a result of the fact they cannot create a block (See Issue #43)

Steps to reproduce the behaviour

Code review block_voting.go

case core.ChainHeadEvent: // got a new header, reset pending state
        bv.resetPendingState(e.Block)
        if bv.synced {
        number := new(big.Int)
                number.Add(e.Block.Number(), common.Big1)
                glog.Infof("ChainHeadEvent: Vote")
                if tx, err := bv.vote(number, e.Block.Hash()); err == nil {
                        if glog.V(logger.Debug) {
                                glog.Infof("Voted for %s on height %d in tx %s", e.Block.Hash().Hex(), number, tx.Hex())
                        }
                } else if glog.V(logger.Debug) {
                        glog.Errorf("Unable to vote: %v", err)
                }
        }

Backtrace

[backtrace]

Simple command line tool to help create genesis file

I created a very simple command line tool to make it a little easier to create a genesis file with voters and block makers. You can find it here: https://github.com/davebryson/quorum-genesis. Given a configuration file of voters and makers it will create the proper storage keys and pre-fund the addresses.

geth --preload does not load script.js

System information

Geth version: geth version
Geth
Version: 1.5.0-unstable
Git Commit: 8c47c29
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Windows/Linux/OSX
Ubuntu 16.03

Branch, Commit Hash or Release: git status
commit 8c47c29

Expected behaviour

geth --preload "script.js" will load the script

Actual behaviour

geth --preload "script.js" doesn't load the script

Steps to reproduce the behaviour

geth --preload "script.js" does not load the script, however once geth has started, >loadScript('script.js') does load the script

Backtrace

[backtrace]

Nodes can execute a transaction multiple times.

System information

Geth version: geth version
Geth
Version: 1.5.0-unstable
Git Commit: 85327f7
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Windows/Linux/OSX
Linux ubuntu-xenial 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Branch, Commit Hash or Release: git status
q1.0.1

Expected behaviour

A node should only execute a transaction once when processing a block, the exception would be blockmaker nodes.

Actual behaviour

As all Quorum nodes run the vote strategy they execute transactions to update their pending state when

They enter the pool (core.TxPreEvent),
When blocks are received from peers
When a new block is inserted (core.ChainheadEvent)
When attempting to create a block (createBlock)

Steps to reproduce the behaviour

N/A - code review

block_voting.go function run
case core.TxPreEvent - applies the transaction to the pending state
case core.ChainHeadEvent - resetof pending state - causing pending transactions to be executed.
case.CreateBlock - non blockmaker and voting nodes - reset of pending state

state_processor.go function process

Process processes the state changes according to the Ethereum rules by running the transaction messages using the statedb and applying any rewards to both the processor (coinbase) and any included uncles.

Backtrace

[backtrace]

Windows: quorum-examples *.sh line endings not compatible with Linux subsystem

Helpful changes / additions to readme -

Minor directory error
ubuntu@ubuntu-xenial:~$ cd quorum-examples/examples/7nodes
should read
ubuntu@ubuntu-xenial:~$ cd quorum-examples/7nodes
On Windows while downloading from git, line returns (^M) are added to .sh / bash scripts. This causes issues when doing ./init.sh or ./start.sh . . .
Easy fix - install dos2unix
sudo apt-get install dos2unix
Run dos2unix on all .sh files before executing bash commands

async contract deployment does not invoke callback function when using --raft

I'm trying to deploy a simple smart contract while running qurom in raft mode.

If my code looks like so:

  var contract = web3.eth.contract(source.info.abiDefinition);
  const options = {
    from: config.gethAccount,
    data: compiled.code,
    gas: 4000001,
  };


  var myContractReturned = contract.new(options, function(err, myContract){
    if(!err) {
      if(!myContract.address) {
        console.log(myContract.transactionHash) // The hash of the transaction, which deploys the contract
        
      } else {
        console.log(myContract.address) // the contract address
      }
    }
    else {
      throw new Error(err)
    }
  });

I get a transaction hash, and i can see that the transaction hash has a receipt (eth.getTransactionReceipt()), however the callback function isn't called the second time to get the actual contract address. Is this because raft is quicker than web3 polling interval/sleep?

Above code works fine in normal (non-raft) mode.

Vagrantfile -- not working behind http_proxy

Please add the following lines in the vagrant file . This will make this work within all corporate firewalls .

config.vm.box = "ubuntu/xenial64"
if Vagrant.has_plugin?("vagrant-proxyconf")
config.proxy.http = ENV['HTTP_PROXY']
config.proxy.https = ENV['HTTPS_PROXY']
config.proxy.no_proxy = "localhost,127.0.0.1"
end

BlockVoting contract getCanonHash function exception

The getCanonHash function does not guard against all input (height) scenarios . For example, when a blockmaker attempts to create its first block, it will call the function with a height of 1, this will throw an exception as no voting periods will have been completed.

The function should check that enough voting periods have been recorded for the height being requested.

There is also an edge-case for the input (height) zero.

Why do all nodes run blockvoting strategy

All nodes irrespective of their block making and/or voting rights run the BlockVoting strategy (Generate block creation events, create a block, vote, apply transactions to pending state, reset pending state & pause/resume block making scheduler). Aren't quorum nodes without a block generation key and/or vote key 'wasting' processing cycles from a consensus perspective.

Unable to send first transaction to node in 7node example

System information

Geth version: geth version
1.5.6-stable

OS & Version: Linux

Branch, Commit Hash or Release:
jpmorganchase/quorum

Expected behaviour

err creating contract Error: Non-200 status code: &{Status:500 Internal Server Error StatusCode:500 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Date:[Wed, 08 Mar 2017 15:46:21 GMT] Server:[Warp/3.2.8]] Body:0xc42090da40 ContentLength:-1 TransferEncoding:[chunked] Close:false Uncompressed:false Trailer:map[] Request:0xc42087fd10 TLS:}

Actual behaviour

Unlocking account and sending first transaction
Contract transaction send: TransactionHash: 0xbfb7bfb97ba9bacbf768e67ac8ef05e4ac6960fc1eeb6ab38247db91448b8ec6 waiting to be mined...
true

Steps to reproduce the behaviour

./start.sh in 7node example

Backtrace

[backtrace]

How to query bootnode to get its enode?

Hi,

I am looking for a way to query the bootnode to get its enode ?

System information

Geth version: geth version
Version: 1.5.0-unstable

OS & Version: Windows/Linux/OSX
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-59-generic x86_64)

Branch, Commit Hash or Release: git status
HEAD detached at v1.0.2

Expected behaviour

Actual behaviour

Steps to reproduce the behaviour

Backtrace

[backtrace]

How to query private stateDB?

I am creating private smart contracts. I am trying to list all the private transactions linked to a particular account. I do not want to query the entire blockchain.

Is there is a way (or the best approach) to query just the private stateDB (.ldb) of a node to find all transactions of an account?

Block creation stops after some time

Geth
Version: 1.5.0-unstable
Git Commit: 6d0bd81
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.4

3 node network vote threshold 3

2 Voter nodes
1 Blockmaker/Voter node
Blocks are created as expected then intermittently stop being produced leaving the console of each node with a long list of txs and no block imported messages:

I0121 19:14:25.660609 internal/ethapi/api.go:1264] Tx(83d753f7202b7d1e6d620d650b1de0327c4ea0874e9d2ef337ff62ff2b61a389) to: &0000000000000000000000000000000000000020
I0121 19:14:34.659610 internal/ethapi/api.go:1264] Tx(d7c79e1287596dafa2e86b67f72bb802bad170f26f002f57ac7dd4432e1dcbf7) to: &0000000000000000000000000000000000000020
I0121 19:14:42.659948 internal/ethapi/api.go:1264] Tx(09eb1594d4022738d144177280f2a6cabb1968e086537a32a340290f5b09a9d0) to: &0000000000000000000000000000000000000020
I0121 19:14:51.660199 internal/ethapi/api.go:1264] Tx(b39171f8b2f600c5f5ee9a61c665b4c8d70f6a32061b461773f014429c98d82f) to: &0000000000000000000000000000000000000020
I0121 19:15:00.660210 internal/ethapi/api.go:1264] Tx(95c3481304b0cddf93cddba72a45576d09fda491da6d35de62d0ff1f8576b40f) to: &0000000000000000000000000000000000000020
I0121 19:15:03.660904 internal/ethapi/api.go:1264] Tx(64ec3674b496cd43b0d71f9095df0501ac71ed21d82416dbf47f6d6f79dea5d5) to: &0000000000000000000000000000000000000020
I0121 19:15:09.661075 internal/ethapi/api.go:1264] Tx(793b8581aa556956539b63a31bfdde0ff6d5444a717ed91ac1c0aed1d18c25c1) to: &0000000000000000000000000000000000000020
I0121 19:15:12.661240 internal/ethapi/api.go:1264] Tx(73b40ebf1ccdb612f97efc2400635dc9743ab5386c7814063713101958e68bca) to: &0000000000000000000000000000000000000020
I0121 19:15:18.662900 internal/ethapi/api.go:1264] Tx(d5990a140a37a6f3ea4c678e0c898f57ff3df78ca52baf4cc56a57b463558fe1) to: &0000000000000000000000000000000000000020
I0121 19:15:21.662153 internal/ethapi/api.go:1264] Tx(ecbb55d4e2216784af76314a46512b19195190bb259f98fb98d30b138aff9b72) to: &0000000000000000000000000000000000000020
I0121 19:15:24.661788 internal/ethapi/api.go:1264] Tx(a8f75c5d89985f6dca95b4fda6701f56347547ab74da5a9e1acdf519cf6c0d00) to: &0000000000000000000000000000000000000020
I0121 19:15:33.662849 internal/ethapi/api.go:1264] Tx(87d4e98edc7797dbb649cc2c1b413f7d7275749c954e052571c1ab3a581f3f30) to: &0000000000000000000000000000000000000020
I0121 19:15:42.663673 internal/ethapi/api.go:1264] Tx(41c681eb76e2aed34f96fd18bd7742237ebd6643f5e0881a4c471d82fb8a5a99) to: &0000000000000000000000000000000000000020
I0121 19:15:50.663912 internal/ethapi/api.go:1264] Tx(abe0ab632e113e12af678ad0079336c2e669611382b1f1105d259b55bd73d5ec) to: &0000000000000000000000000000000000000020
I0121 19:15:58.664577 internal/ethapi/api.go:1264] Tx(4e6285d601f6c8fe4a4998060acd533bd29f0af4959b3d7d3698d31c2204cde8) to: &0000000000000000000000000000000000000020
I0121 19:16:07.664887 internal/ethapi/api.go:1264] Tx(7433452e149ef2855b69b4cf70e87cebb1d4d0f497133c643330ceee9e90b326) to: &0000000000000000000000000000000000000020
I0121 19:16:14.665266 internal/ethapi/api.go:1264] Tx(842ee45bada094b6d2d423b0cf58c60dd096e774eccca88de04af50aa6b52912) to: &0000000000000000000000000000000000000020

When restarting the Blockmaker/Voter node, block creation continues but blocks are not synced to remaining voting nodes, console output shows same never ending list of txs as illustrated above.

After restarting the bootnode and repeatedly restarting the 2 voter nodes, they were able to sync up and continue importing blocks, however I suspect the blockmaker will stop producing blocks however again after some time the BlockMaker/Voter node (I presume) ceases to produce blocks.

Any help or ideas are greatly appreciated!

Issue with Private Contract Deloyment

System information

Geth version: geth version
1.5.0-unstable-85327f74

OS & Version: Windows/Linux/OSX
Ubuntu 16.04.1 LTS

Branch, Commit Hash or Release: git status
Master

Expected behavior

Private Contract Deployment should succeed.

Actual behavior

Behavior is inconsistent, it succeeds after 4-5 attempts. When it fails I see error in constellation log file as unknown recipient. Log it attached here with.

Steps to reproduce the behavior

I have 6 Nodes each node having two accounts and are configured as Voter & Block maker.
I am trying to deploy contract from node 6 as private to Node 1,2,3,4,5

Constellation log with the error information is attached here with for your reference.
constellation6.txt

Please advise.

Unable to deploy contract while running start.sh

Q1: When running init - No etherbase / account is set. Is that right?
Q2: When running start - account[0] is not unlocked (does not exist?) and also deploying contract fails

What has failed and how do I set up the scripts to work as intended?

Private transactions, public contracts and consensus.

I was wondering how public contracts and private transactions can interact in quorum, if at all. I haven't found in the documentation if this is possible.

For example, given this scenario:

person A sends a public transaction creating:

contract MyContract
{
    uint public myUint;
    function setMyUint(uint _myUint)
    {
        myUint = _myUint;
    }
}

person B sends a private transaction (with privateFor: public key for person B) to MyContract; setting myUint = 1;
A and B now call MyContract.myUInt();

A would get 0 but it is not clear what B would get. If public/private state mixing isn't possible this scenario also causes some confusion with a private contract between 2 parties, and a transaction changing the state shared with only 1 of those participants. So can someone query the contract's state in two ways: one with only public knowledge of the state, and another which includes any private knowledge?

If the later is the case, what would happen if the public contract could send ether to an address? ie.

contract MyContract
{
    function sendEther(address beneficiary)
    {
       beneficiary.send(this.balance);
    }
}

If a private transaction calls sendEther, what would everyone think the contract's and the beneficiary's balances are?

In the case that public contracts and private transactions can't be mixed, I'm not sure what would happen if the 2nd contract was created privately and a private transaction sent ether to another address. Could you check someone's "private balance" and have it behave like a private token?

Thanks in advance.

Why make empty blocks?

I am wondering why block making in quorum still makes (mines) empty blocks with no transactions (bloating the state storage). I can't imagine any use cases where this is necessary. When mining on a private network with ethereum geth, there's a way to use a javascript "hack" to prevent empty blocks from being mined. Hoping this feature will be baked into the client for quorum. I'd be happy to take a crack at developing it and creating a pull request, just wondering if theres any reason its not viable.

Private transactions and setting PrivateFor - Question

In the 7 nodes example, when deploying the simple contract the privateFor is set to the public key of the constellation node running on Node7.

Is privateFor always set to the public key(s) of the intended constellation node(s)? Or can I send a private transaction to any user in the Quorum network by setting theprivateFor to the public key associated with a specific user (externally owned account)?

HTTP_PROXY and HTTPS_PROXY are not automatically forwarded to the Vagrant VM

System information

Geth version: 1.3.5
OS & Version: Windows 8.1
Commit hash : (if develop)

On firing Vagrant up, I am facing the following issue

==> default: Running provisioner: shell...
default: Running: C:/Users/00000/AppData/Local/Temp/vagrant-shell20161130-4056-1lsawh4.sh
==> default: mesg:
==> default: ttyname failed
==> default: :
==> default: Inappropriate ioctl for device
==> default: Cannot add PPA: 'ppa:~ethereum/ubuntu/ethereum'.
==> default: ERROR: '~ethereum' user or team does not exist.
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

Are there steps I am missing ? also what's the password used for ubuntu user for this virtual box image ? if that's available, I can try logging into the machine separately and check issue with ppa. I have http_proxy and https_proxy set.

Private Transaction from solidity code ?

Hello,

I have got a private contract that need to interact with another private contract (from within the code)
Is this operation going to be seen as a private transaction ?

How does Quorum handle this with regards to private / public transactions ?

Thank you

Quorum node panic when starting with local constellation node stopped

System information

Geth version: geth version
Geth
Version: 1.5.0-unstable
Git Commit: 85327f7
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.7.3
OS: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Windows/Linux/OSX
Linux ubuntu-xenial 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Branch, Commit Hash or Release: git status
HEAD detached at q1.0.1

Expected behaviour

Quorum node should generate a error/warning event that can be readily monitored. This is inconsistent with error handling if constellation node goes down after quorum node has started. If both Quorum and Constellation nodes are expected to be up then shouldn't Quorum node actively check status of its 'paired' Constellation node.

Actual behaviour

Quorum node fails to start with a panic

Steps to reproduce the behaviour

Start quorum node with local constellation node stopped.

Backtrace

nohup: appending output to 'nohup.out'
panic: MustNew error: Get http+unix://c/upcheck: dial unix qdata/tm7.ipc: connect: connection refused

goroutine 1 [running]:
panic(0xc20d20, 0xc4201d2b90)
/usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/ethereum/go-ethereum/private/constellation.MustNew(0xc42000e00f, 0x8, 0xc42000e00f)
/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/private/constellation/constellation.go:76 +0x114
github.com/ethereum/go-ethereum/private.FromEnvironmentOrNil(0xd5bfeb, 0xe, 0x153bf40, 0xc420045ea0)
/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/private/private.go:19 +0x52
github.com/ethereum/go-ethereum/private.init()
/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/private/private.go:22 +0x67
github.com/ethereum/go-ethereum/core.init()
/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/vm_env.go:165 +0xf4
github.com/ethereum/go-ethereum/cmd/utils.init()
/home/ubuntu/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/cmd/utils/version.go:65 +0x76
main.init()
github.com/ethereum/go-ethereum/cmd/geth/_obj/_cgo_import.go:6 +0x58

bootnode 7nodes example

Hi,

In the 7 nodes example, the bootnode's enode is pre-defined. How did this get generated ?

Is the bootnode simply used as a discovery mechanism?

Also, can I start my quorum network without a bootnode. I guess, I can add peers "manually" after each individual node is started ?

Thanks