Precision in definition specification is precisely what you were requesting .... do it how you like of course.phelix wrote:Though this is more precise it is also harder to understand, especially for non native English speakers. If there are no strong arguments I suggest we stick to "signer", it seems the majority is at least ok with it.moa wrote:I think "endorser" is the closest legally equivalent role ... since you are effectively transferring signing authority (proof of ownership) to a different signer (priv key).
Decide on a general procura field
Re: Decide on a general procura field
Re: Decide on a general procura field
The "signer" address(es) shall be used for signing like the address holding a name.
Priority:
highest: name holding address
signer[0]
signer[1]
signer[2]
...
or
Priority:
highest: name holding address
signer[0]
signer[1]
signer[2]
...
Code: Select all
{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"]}
Code: Select all
{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}
Re: Decide on a general procura field
I think we should clarify that "signing like the address holding a name" does not mean it is allowed to sign namecoin transactions on behalf of that name, but instead this is only the case for certain high-level applications (like file verification and NameID once I implement it) which explicitely claim themselves they want to support "signer". Furthermore, what exactly is the significance of the priority ordering? While it makes sense intuitively, I fail to see a situation where it would matter. Do you have a particular example in mind?phelix wrote:The "signer" address(es) shall be used for signing like the address holding a name.
Priority:
highest: name holding address
signer[0]
signer[1]
signer[2]
...
Sounds good. What about allowing the first one to be just a single string instead of an array, likephelix wrote:orCode: Select all
{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"]}
Code: Select all
{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}
Code: Select all
{"signer":"N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"}
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
Re: Decide on a general procura field
feel free to work out a nice and short wordingdomob wrote:I think we should clarify that "signing like the address holding a name" does not mean it is allowed to sign namecoin transactions on behalf of that name, but instead this is only the case for certain high-level applications (like file verification and NameID once I implement it) which explicitely claim themselves they want to support "signer".phelix wrote:The "signer" address(es) shall be used for signing like the address holding a name.
Priority:
highest: name holding address
signer[0]
signer[1]
signer[2]
...
Nah, I just got the idea and thought I would write it down in case a conflict should arise. It is pretty clear though that the holding address has highest priority as it "can change the others".Furthermore, what exactly is the significance of the priority ordering? While it makes sense intuitively, I fail to see a situation where it would matter. Do you have a particular example in mind?
I don't mind. I thought about it, too, but was feeling generous on blockchain characters. Most of the time it will only be one signer address I guess...Sounds good. What about allowing the first one to be just a single string instead of an array, likephelix wrote:orCode: Select all
{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"]}
Code: Select all
{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}
? I think this makes sense and is not too hard to implement from an applications point of view. (For OTR fingerprints I currently support both versions in my experimental work there.)Code: Select all
{"signer":"N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"}
Code: Select all
The "signer" address(es) shall be used in high level applications (in contrast to regular namecoin transactions) for signing interchangeably to the address holding the name.
Code: Select all
{"signer":"N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"}
Code: Select all
{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Decide on a general procura field
Am I correct in assuming that functionality like multi-factor authentication (e.g. require 2 keys to sign a NameID message) should be handled by multisig addresses (with a single multisig address listed in the "signer" field), not by listing multiple non-multisig addresses in the "signer" field? Anyone know if a multisig address in Bitcoin can sign messages like standard addresses can?
Has "signer" been implemented in NameID or any other implementations? If I possessed an important id/ name, I would be concerned about unlocking my wallet every time I wanted to login to a website.
Has "signer" been implemented in NameID or any other implementations? If I possessed an important id/ name, I would be concerned about unlocking my wallet every time I wanted to login to a website.
Re: Decide on a general procura field
No, not yet, but it is on my list of things to do next. (Actually it even was before this feature was discussed here, since I agree with you that it is very good to keep important names safe while you may want to log in from not so secure computers / unlock the wallet often.) I hope that it will be done in the next weeks or at the very latest a few months, depending on how much time I find for it.biolizard89 wrote:Has "signer" been implemented in NameID or any other implementations? If I possessed an important id/ name, I would be concerned about unlocking my wallet every time I wanted to login to a website.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 541
- Joined: Mon May 20, 2013 12:03 pm
- Contact:
Re: Decide on a general procura field
Yes. That's correct.biolizard89 wrote:Like domob I don't understand this concern. Namecoin is generic name/value storage; no one is required to use certain fields. It is beneficial to have a specification for such things because the people who do have a use for it will not have to design it separately for different use cases, and will be able to interoperate with each other. Not everyone uses the import field right now either, but as I posted in another thread, it's useful for cold storage purposes. When people have ideas for Namecoin use cases, they shouldn't have to get approval for the use case existing; they should just start writing a specification and get feedback to make the spec as good as possible.virtual_master wrote:- are you sure that we need this ? May be we can make a voting on bitcointalk.org to see if it is needed or not.
If we implement such a feature then we should be sure it is needed and it should be cost efficient. If there will be 100 uses/year and each costs 0.02 namecoins then for 2 namecoins it is not economic and would only confuse the others(who don't use it).
I didn't want to stop anybody to implement a new feature just asked if you are convinced if it is necessary.
Sure. If somebody will need it in the future it will be there.
Thanks.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S