BitShares Forum
Main => Technical Support => Topic started by: ElMato on June 09, 2015, 07:48:34 pm
-
While we wait for the official testnet, anyone is trying to run the code posted yesterday?
After compiling and running witness_node im getting.
No witnesses configured! Please add witness IDs and private keys to configuration.
So i edit the config.ini (there is no config.json as github says)
and set
witness-id = "1.2.0"
since the privkey is already configured for this witness. (is this reasoning ok??)
private-key = ["1.2.0","aeebad4a796fcc2e15dc4c6061b45ed9b373f26adfc798ca7d2d8cc58182718e"]
10 assert_exception: Assert Exception
fc::to_uint64( s.substr( 0, first_dot ) ) == SpaceID && fc::to_uint64( s.substr( first_dot+1, second_dot-first_dot-1 ) ) == TypeID:
{}
th_a object_id.hpp:182 from_variant
{"var":"1.2.0"}
th_a object_id.hpp:184 from_variant
If i set the witness id to witness-id = "1.7.0"
The node starts ....
Any hints?
2375001ms th_a witness.cpp:129 operator() ] Not producing block because production is disabled.
2380000ms th_a witness.cpp:171 block_production_loo ] slot: 435756 scheduled_witness: 1.7.2 scheduled_time: 2015-06-09T19:39:40 now: 2015-06-09T19:39:40
2380001ms th_a witness.cpp:129 operator() ] Not producing block because production is disabled.
2385000ms th_a witness.cpp:171 block_production_loo ] slot: 435757 scheduled_witness: 1.7.3 scheduled_time: 2015-06-09T19:39:45 now: 2015-06-09T19:39:45
2385000ms th_a witness.cpp:129 operator() ] Not producing block because production is disabled.
2390001ms th_a witness.cpp:171 block_production_loo ] slot: 435758 scheduled_witness: 1.7.4 scheduled_time: 2015-06-09T19:39:50 now: 2015-06-09T19:39:50
2390001ms th_a witness.cpp:129 operator() ] Not producing block because production is disabled.
2395000ms th_a witness.cpp:171 block_production_loo ] slot: 435759 scheduled_witness: 1.7.7 scheduled_time: 2015-06-09T19:39:55 now: 2015-06-09T19:39:55
2395000ms th_a witness.cpp:129 operator() ] Not producing block because production is disabled.
-
Set this in your config.ini in witness_node_data_dir:
# Enable block production, even if the chain is stale
enable-stale-production = true
# ID of witness controlled by this node (e.g. "1.7.0", quotes are required, may specify multiple times)
witness-id = "1.7.0"
witness-id = "1.7.1"
witness-id = "1.7.2"
witness-id = "1.7.3"
witness-id = "1.7.4"
witness-id = "1.7.5"
witness-id = "1.7.6"
witness-id = "1.7.7"
witness-id = "1.7.8"
witness-id = "1.7.9"
-
Thanks svk, now its producing blocks.
Do you know which private keys are the witnesses using to sign the blocks?
another question:
When i run the cli_client after i get the "new" prompt i set set_password "123" and i get null as response.
Then when i run the cli_client again and try to unlock by doing unlock "123"" i get.
{"s":"error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt"}
-
Added this to the README.
-
Thanks svk, now its producing blocks.
Do you know which private keys are the witnesses using to sign the blocks?
another question:
When i run the cli_client after i get the "new" prompt i set set_password "123" and i get null as response.
Then when i run the cli_client again and try to unlock by doing unlock "123"" i get.
{"s":"error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt"}
Vikram in issue #23:
Genesis secrets for init witnesses are currently based on genesis_private_key. This won't be doable for real init witnesses with real private keys.
Since the bit commitment needs to support a "never committed" state to deal with new witnesses who have never produced a block, we should simply set the genesis witnesses to this state.
I just did "set_password password" I think. Try it without the quotes maybe?
-
I just needed to do this upon cloning the new public repo and it definitely works. @theoretical you could probably add this to the README as well:
Upon first launch of cli_wallet:
set_password password
unlock password
To save the wallet file you should close then reopen the cli_wallet.
Before doing any transactions etc you need to import the private keys for the 1.3.11 account:
import_key "1.3.11" "5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"
Then you can try some commands like these:
transfer "1.3.11" "1.3.1" 100 CORE "memo" true
dbg_make_mia 1.3.11 USD
sell_asset 1.3.11 1000 CORE 100 USD 100000 false true
short_sell_asset 1.3.11 1000 USD 1000 true
-
Excellent, everything is working now.
Based on
https://github.com/cryptonomex/graphene/blob/master/libraries/chain/include/graphene/chain/types.hpp
typedef object_id< protocol_ids, account_object_type, account_object> account_id_type;
1.2.X => keys
1.3.X => account
1.4.X => asset
1.7.X => witness
...
Looking at the tx generated by
transfer "1.3.11" "1.3.1" 100 CORE "memo" true
{
"ref_block_num": 832,
"ref_block_prefix": 1233679879,
"relative_expiration": 3,
"operations": [[
0,{
"fee": {
"amount": 0,
"asset_id": "1.4.0"
},
"from": "1.3.11",
"to": "1.3.1",
"amount": {
"amount": 10000000,
"asset_id": "1.4.0"
},
"memo": {
"from": "1.2.1",
"to": "1.2.0",
"nonce": "11962994495084021359",
"message": "001e77e19727022f7d12e3571bf30c4b"
}
}
]
],
"signatures": [[
"1.2.1",
"1f6a44dc809adfced585aa9f393d76061db3cec77d0fa0c65bb07ff0d48426f9175c317351ac10e3e84d580c853c01285913937136d75b1d74c594d9e62ebf4591"
]
]
}
It has only one operation (transfer_operation), that is a deposit+withdraw combination from the 0.9.X version.
That is signed by the key 1.2.1 which is the only authority that 1.3.11 has for active.
{"id":1, "method":"call", "params":[0,"get_accounts",[["1.3.11"]]]}
Wow this is excellent ... even if i should be screaming for the amount of code we need to throw away :)
-
I am glad you approve of the new protocol design.
-
Out of curiosity, why are the witness IDs dot-delimited?
-
Out of curiosity, why are the witness IDs dot-delimited?
The github readme has some answers,
https://github.com/cryptonomex/graphene
look for What is the meaning of a.b.c numbers?
-
wow, that's really better than before
Excellent, everything is working now.
Based on
https://github.com/cryptonomex/graphene/blob/master/libraries/chain/include/graphene/chain/types.hpp
typedef object_id< protocol_ids, account_object_type, account_object> account_id_type;
1.2.X => keys
1.3.X => account
1.4.X => asset
1.7.X => witness
...
Looking at the tx generated by
transfer "1.3.11" "1.3.1" 100 CORE "memo" true
{
"ref_block_num": 832,
"ref_block_prefix": 1233679879,
"relative_expiration": 3,
"operations": [[
0,{
"fee": {
"amount": 0,
"asset_id": "1.4.0"
},
"from": "1.3.11",
"to": "1.3.1",
"amount": {
"amount": 10000000,
"asset_id": "1.4.0"
},
"memo": {
"from": "1.2.1",
"to": "1.2.0",
"nonce": "11962994495084021359",
"message": "001e77e19727022f7d12e3571bf30c4b"
}
}
]
],
"signatures": [[
"1.2.1",
"1f6a44dc809adfced585aa9f393d76061db3cec77d0fa0c65bb07ff0d48426f9175c317351ac10e3e84d580c853c01285913937136d75b1d74c594d9e62ebf4591"
]
]
}
It has only one operation (transfer_operation), that is a deposit+withdraw combination from the 0.9.X version.
That is signed by the key 1.2.1 which is the only authority that 1.3.11 has for active.
{"id":1, "method":"call", "params":[0,"get_accounts",[["1.3.11"]]]}
Wow this is excellent ... even if i should be screaming for the amount of code we need to throw away :)
-
so the balance is belong to account ID, not account name, not active key.
this is really good!
we can get balance very simple,
build transaction very simple,
send dividents very simple,
excellent, BM!
-
How does key generation work?
I can't figure out how to generate a new key inside the wallet.
When I attempt to register a key generated outside of the wallet, it kills the cli_client
Is key generation/registration not implimented yet?