Decide on a general procura field

moa
Posts: 255
Joined: Mon May 23, 2011 6:13 am

Re: Decide on a general procura field

Post by moa »

phelix wrote:
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).
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.
Precision in definition specification is precisely what you were requesting .... do it how you like of course.

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Decide on a general procura field

Post by phelix »

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]
...

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"]}
or

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

domob
Posts: 1127
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Decide on a general procura field

Post by domob »

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]
...
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:

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"]}
or

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}
Sounds good. What about allowing the first one to be just a single string instead of an array, like

Code: Select all

{"signer":"N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"}
? 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.)
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Decide on a general procura field

Post by phelix »

domob wrote:
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]
...
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".
feel free to work out a nice and short wording :mrgreen:
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?
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".
phelix wrote:

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"]}
or

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}
Sounds good. What about allowing the first one to be just a single string instead of an array, like

Code: Select all

{"signer":"N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"}
? 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.)
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...

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"}
or

Code: Select all

{"signer":["N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq","N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"]}
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Decide on a general procura field

Post by biolizard89 »

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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

domob
Posts: 1127
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Decide on a general procura field

Post by domob »

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.
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.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Decide on a general procura field

Post by virtual_master »

biolizard89 wrote:
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).
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.
Yes. That's correct.
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

Post Reply