Mike Belshe [ARCHIVE] on Nostr: 📅 Original date posted:2013-12-19 📝 Original message:Hey Peter - I think this ...
📅 Original date posted:2013-12-19
📝 Original message:Hey Peter -
I think this is a super list. A couple of thoughts:
a) In the section on multi-sig and multi-factor, I think we can split these
apart. Multi-factor user authentication is very valuable and not the same
as multi-factor signing, which is a second level of complexity. The
multi-factor auth can be off-blockchain, e.g. authenticating with SMS
message to your phone or Google Authenticator challenge. Given the state
of malware today, I personally would propose two requirements:
1) wallets SHOULD use multi-factor authentication before authorizing
access to a wallet (e.g. view balances, addresses, transactions, etc)
2) wallets MUST use multi-factor auth before signing a transaction.
[note: I recognize that MUST might be too aggressive right now, but I
wouldn't use a wallet without it. this can also be impractical for
server-side wallets]
b) Multi-factor signing (e.g. P2SH) may be too early to really define. But
here are some issues which have come up from my own personal development
experience:
- Wallets SHOULD NOT create two keys on a single host or device
- Wallets SHOULD provide a way to import external public keys which can
be used as part of a P2SH address
Slightly off topic: For P2SH, address creation requires the public key,
not the public hash of an address. For me, this has made it difficult to
import keys created through out-of-band sources. Most wallets/key
generators/etc only provide the address and not the public key, and this is
a hinderance to easy P2SH creation off host. It would be great if there
were a way to address this, but I don't know how.
c) Small word-choice nit: I had to go lookup the meaning of "SHALL" (I now
know it is the same as MUST). I think most RFCs just use MUST these days.
Thanks,
mike
On Thu, Dec 19, 2013 at 8:32 AM, Drak <drak at zikula.org> wrote:
> On 19 December 2013 16:04, Amir Taaki <genjix at riseup.net> wrote:
>
>> About signing each commit, Linus advises against it:
>>
>> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
>
>
> Yeah, it makes no sense after reading it. Nice catch.
>
> However, his recommendation for signing tags with `git tag -s` should
> probably be incorporated into the spec as a MUST.
>
> Drak
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131219/80e6438c/attachment.html>;
📝 Original message:Hey Peter -
I think this is a super list. A couple of thoughts:
a) In the section on multi-sig and multi-factor, I think we can split these
apart. Multi-factor user authentication is very valuable and not the same
as multi-factor signing, which is a second level of complexity. The
multi-factor auth can be off-blockchain, e.g. authenticating with SMS
message to your phone or Google Authenticator challenge. Given the state
of malware today, I personally would propose two requirements:
1) wallets SHOULD use multi-factor authentication before authorizing
access to a wallet (e.g. view balances, addresses, transactions, etc)
2) wallets MUST use multi-factor auth before signing a transaction.
[note: I recognize that MUST might be too aggressive right now, but I
wouldn't use a wallet without it. this can also be impractical for
server-side wallets]
b) Multi-factor signing (e.g. P2SH) may be too early to really define. But
here are some issues which have come up from my own personal development
experience:
- Wallets SHOULD NOT create two keys on a single host or device
- Wallets SHOULD provide a way to import external public keys which can
be used as part of a P2SH address
Slightly off topic: For P2SH, address creation requires the public key,
not the public hash of an address. For me, this has made it difficult to
import keys created through out-of-band sources. Most wallets/key
generators/etc only provide the address and not the public key, and this is
a hinderance to easy P2SH creation off host. It would be great if there
were a way to address this, but I don't know how.
c) Small word-choice nit: I had to go lookup the meaning of "SHALL" (I now
know it is the same as MUST). I think most RFCs just use MUST these days.
Thanks,
mike
On Thu, Dec 19, 2013 at 8:32 AM, Drak <drak at zikula.org> wrote:
> On 19 December 2013 16:04, Amir Taaki <genjix at riseup.net> wrote:
>
>> About signing each commit, Linus advises against it:
>>
>> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
>
>
> Yeah, it makes no sense after reading it. Nice catch.
>
> However, his recommendation for signing tags with `git tag -s` should
> probably be incorporated into the spec as a MUST.
>
> Drak
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131219/80e6438c/attachment.html>;