Comments (21)
Okay, lets so a vote (using thumbs-up/down) to remove this. Please vote thumbs down if you want to keep or extend it to allow multiple-keys.
from bp-info-standard.
I would prefer to remove it at this time. If someone comes up with a really good use case for it in the future, then can be re-discussed. I have not yet seen anyone say what business value this provides.
from bp-info-standard.
Or maybe allow multiple keys?
from bp-info-standard.
Follow up question:
Is producer_public_key
actually used for anything? Why is it part of the spec? It's never shown to the user, so how will voting tools use this signing key? What purpose does it serve? If it serves no purpose, we should remove it.
from bp-info-standard.
Unless the idea is to extend it with a signature as well, as suggested in #10.
from bp-info-standard.
Oh, I was confused too :)
My vote is/was to remove it.
from bp-info-standard.
My own opinion, since many BPs will (and should) have multi-sig accounts this gets complicated.
Technically the key used with regproducer is the one used to mint blocks so effectively you vote to allow someone to use that key to mint.
On the other hand that key may be rotated more frequently...
from bp-info-standard.
I would suggest allowing multiple keys with their role description (owner, active, block signing, etc...).
from bp-info-standard.
What about the following change?
From:
{
"producer_account_name": "",
"producer_public_key": "",
"org": {
"candidate_name": "",
...
To:
{
"producer_account_name": "",
"permissions": {
"owner": "",
"active": "",
"sign": ""
},
"org": {
"candidate_name": "",
...
from bp-info-standard.
Right now tooling seems to be validating it against the signing key. Example:
https://validate.eosnation.io/producers/eosdacserver.html
field=<producer_public_key> does not match between bp.json and regproducer
If that's the case, this should not be a high level field, but a field for individual nodes. We should then be able to switch between our primary producer and our backup producer without seeing errors like this. Each signing key should be seen as valid. If we add our producing nodes to the bp.json, then there should be no endpoint requirements at all since those should remain private and unknown for producing nodes.
"node_type": "producer",
"producer_key": "EOS7aBPDACAn1SpJDjmaZHSEUgqfNWdUaNawVZhVuEWUx5aoepJf6",
So essentially producer_key is only required for node_type = producer and all the endpoints are only required for node_type != "producer"
from bp-info-standard.
I don't think it's useful. We have account, so if there is a reason someone needs a key they could get it from the chain.
from bp-info-standard.
@eosrio sorry, I was confused by your vote question earlier. I thought it was a thumbs down to remove. I've changed my vote to a thumbs up for removal. When we switch back and forth between producing nodes, we don't want to also have to update the signing key. It makes no sense as the signing key is defined by the value in listproducers, not by what is in a json file on a website.
from bp-info-standard.
There is one use case where I know where having the key is useful. That is when someone steals a BP's identity entirely it is obvious if the key doesn't match. This already happened. (regproduce using an existing BP's URL).
from bp-info-standard.
Removing the block signing key from the bp.json
standard would also be my vote.
If someone steals your BP key, you've got bigger problems then your bp.json
not syncing up.
The block signing key is already registered on the blockchain, no need to duplicate this information in the bp.json
.
from bp-info-standard.
I think you missed my point. If someone steals your bp.json and makes no changes, the block signing key will not match. (I am not saying they are stealing your key).
Anyway, as I said in the original thread, I'm fine to also remove this field entirely.
from bp-info-standard.
If I'm understanding that case correctly, producer_account_name provides the same usefulness as it wouldn't match as well. Is that right?
But yeah, I think we are all in agreement to remove it.
from bp-info-standard.
@matthewdarwin oh yes, if someone takes over your bp.json
at least you have a way to check on chain if the information is accurate & matching.
Good argument.
from bp-info-standard.
It's not easy to steal an identity entirely because they would have to register a different bp account name and have a different website to host their fraudulent bp.json. The account name, url, and signing key are already on the blockchain. Signing keys can change often as BPs move from primaries to backups and back again. Those changes are seen as false positives for a problem under the current schema.
I vote to ditch it.
from bp-info-standard.
I agree that this needs to be remove. In our case we use different keys for different nodes, so everytime we change node the keys dont match.
from bp-info-standard.
We removed this on our bp.json and our validation failed on the portal side.
This is still required on the schema
https://github.com/eosrio/bp-info-standard/blob/master/schema.json#L35
Can we get the Schema updated?
from bp-info-standard.
Yes, updating soon
from bp-info-standard.
Related Issues (20)
- Add signature option to bp.json HOT 2
- Attribute not described in documentation HOT 3
- Remove producer_public_key HOT 1
- Show the port numbers or not on API endpoints when port number is 'standard' HOT 2
- Link to code of conduct HOT 1
- node types are confusing HOT 17
- Add Testnet Nodes Info / Chain Id info in Nodes json HOT 5
- Schema does not match the example provided. HOT 1
- bp.json on-chain does not match the one provided in regproducer URL HOT 1
- Add an optional array of URLs linking to projects which benefit the community HOT 4
- Also accept array for github_user HOT 1
- Add 'medium' as a valid social. medium.com/@<username>
- Add firehose as type of feature HOT 1
- Add Discord under 'social' HOT 1
- Extension of bp-info-standard HOT 2
- Define standard for IBC bridges HOT 1
- Follow RFC5785 for /.well-known/ URIs HOT 3
- Add country code information to readme
- Extend the node object to allow bnet_endpoint HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bp-info-standard.