As we are now trying to get our 脨app to work in Mist it would be nice if we could point the mist client to a private chain so our remote devs could just download a json file that defines our private network (networkid, bootnodes, etc...) and start the Mist instance against that for better collaboration on the UI work. Something like this proposed data structure would be nice:
{"networkId": 4734, "bootnodes": ["array","of","nodeUrls"....], "genesis": { .... genesis json } }
Then we can startup Mist locally using mist --config
You can simply run geth before you start mist.
If you have a private chain using a different datadir, simply add the --ipcpath flag pointing to the default datadir:
geth --ipcpath /Users/you/Library/Ethereum/geth.ipc --datadir ....
I'd like to propose this be reopened and reconsidered.
I'd like to set up a private network for some testing between users and to demo Ethereum to them in a private setting. However, going through the standard geth procedure is annoying.
Ideally, I can just distribute a test JSON (as documented in the OP's post) that they can drag and drop somewhere (special private net option?).
Perhaps a field can be added for a custom name as well (so I can override ETH to something else), though this is just a wishlist item at best.
Not high-priority, of course, but would definitely be nice to have for ease-of-use.
This issue seems to be duplicated by #1452, and related to #797, #699.
Fatal: You can simply run geth before you start mist.
But there's an anomaly in the mist-wallet锛欵rror starting protocol stack: listen tcp :30303: bind: address already in use
@huzunjie I'm getting the same error. I've tried using different ports for geth and the passing the same port to mist when invoking it.
@huzunjie I figured out a solution. These guys above should have told us this. They closed this for the wrong reason. The soluton is:
When invoking geth pass it --ipcpath "~/geth.ipc"
Then when invoking mist pass it --rpc "~/geth.ipc"
And wah'la! It connects to the private chain!
This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.
Most helpful comment
@huzunjie I figured out a solution. These guys above should have told us this. They closed this for the wrong reason. The soluton is:
When invoking geth pass it --ipcpath "~/geth.ipc"
Then when invoking mist pass it --rpc "~/geth.ipc"
And wah'la! It connects to the private chain!