Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-11 🗒️ Summary of this message: Matt wants to ...
📅 Original date posted:2011-08-11
🗒️ Summary of this message: Matt wants to ship wallet encryption and multisign patch, but documentation is lacking. He also wants more testing and a dedicated support organization. There is a need to un-hardcode fee handling, but no good solutions have been proposed yet.
📝 Original message:> > 3. Wallet security. I'd like to get Matt's wallet encryption shipped
> > soon, along with all or part of groffer's Multisign patch (#319 --
> > since that will enable the creation of trojan-resistant secure wallet
> > solutions).
>
> IMO the only thing lacking is docs. There is no real admin guide
> describing how to prepare bitcoind installations for encryption;
> doc/README does not mention RPC encryptwallet at all, nor does it
> describe the various states your wallet may be in, when before and
> after encryptwallet has been run. The information is very general,
> and not adequate for a competent admin to be able to evaluate. It
> does not describe encryption method or other security parameters. It
> does not describe the specific technical relationship between the
> master key and other keys.
My fault, Ill write something up on the train back today.
>
> > 5. Testing. I don't have time to personally test every PULL request,
> > but if a pull involves more than trivial code changes I'm not going to
> > pull it unless it has been thoroughly tested. We had a very good rule
> > at a company I used to work for-- programmers were NOT allowed to be
> > the only ones to test their own code. Help finding money and/or people
> > for a dedicated "core bitcoin quality assurance team" is welcome.
> > More unit tests and automated testing is also certainly welcome.
>
> I think Q/A will naturally grow out of some sort of dedicated support
> organization, rather than have a dev fiat requirement. Testing like
> that is always desireable in the "I'd love it, if it were this way"
> vein, but not always realistic at all for open source projects.
> Especially with open source, time has shown that the best testing
> comes from the field, and we have the biggest test lab in the world:
> the Internet. So IMO focus less on roadblocks to publishing software,
> and more on widely distributed test software.
>
> For new features, simple "it works" test at a minimum seems
> reasonable, most of the time. But in open source the testing and such
> tends to happen in the periphery, by organizations and individuals
> with the incentive to focus on those issues.
>
> In my recent emails describing linux-next and a proposed
> "bitcoin-next", one attribute of linux-next is that it is run through
> automated tests on a daily basis, right after the merge is complete.
> It forms a useful layer on top of the primary linux project & tree.
Jenkins + a large enough test suite could do very nice automatic sanity
testing IMHO...that is what it is designed for (even if not to
automatically test pre-merge, but it could be adapted). Many pull
requests build on Linux, but not on MinGW, OSX, etc so just that would
be useful IMHO.
> Not a big deal to me, I never use GUI :)
>
> > Un-hardcode fee handling (anybody already working on this?)
>
> Has anyone actually come up with a good idea to code?
>
> This is a widely acknowledged problem, sure, but where are the good
> solutions, even on paper?
Sipa's stuff is quite good IMHO, it still has some problems left to
solve (like choosing minor details of the underlying priority algorithm)
but aside from those, I think it could work. I'm not sure if sipa wants
to just publish the stuff he did so far and let this list debate on the
remaining details and eventual implementation, or if he wanted to come
up with something complete before publishing, it up to him, but it is
doable.
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110811/58746a63/attachment.sig>;
🗒️ Summary of this message: Matt wants to ship wallet encryption and multisign patch, but documentation is lacking. He also wants more testing and a dedicated support organization. There is a need to un-hardcode fee handling, but no good solutions have been proposed yet.
📝 Original message:> > 3. Wallet security. I'd like to get Matt's wallet encryption shipped
> > soon, along with all or part of groffer's Multisign patch (#319 --
> > since that will enable the creation of trojan-resistant secure wallet
> > solutions).
>
> IMO the only thing lacking is docs. There is no real admin guide
> describing how to prepare bitcoind installations for encryption;
> doc/README does not mention RPC encryptwallet at all, nor does it
> describe the various states your wallet may be in, when before and
> after encryptwallet has been run. The information is very general,
> and not adequate for a competent admin to be able to evaluate. It
> does not describe encryption method or other security parameters. It
> does not describe the specific technical relationship between the
> master key and other keys.
My fault, Ill write something up on the train back today.
>
> > 5. Testing. I don't have time to personally test every PULL request,
> > but if a pull involves more than trivial code changes I'm not going to
> > pull it unless it has been thoroughly tested. We had a very good rule
> > at a company I used to work for-- programmers were NOT allowed to be
> > the only ones to test their own code. Help finding money and/or people
> > for a dedicated "core bitcoin quality assurance team" is welcome.
> > More unit tests and automated testing is also certainly welcome.
>
> I think Q/A will naturally grow out of some sort of dedicated support
> organization, rather than have a dev fiat requirement. Testing like
> that is always desireable in the "I'd love it, if it were this way"
> vein, but not always realistic at all for open source projects.
> Especially with open source, time has shown that the best testing
> comes from the field, and we have the biggest test lab in the world:
> the Internet. So IMO focus less on roadblocks to publishing software,
> and more on widely distributed test software.
>
> For new features, simple "it works" test at a minimum seems
> reasonable, most of the time. But in open source the testing and such
> tends to happen in the periphery, by organizations and individuals
> with the incentive to focus on those issues.
>
> In my recent emails describing linux-next and a proposed
> "bitcoin-next", one attribute of linux-next is that it is run through
> automated tests on a daily basis, right after the merge is complete.
> It forms a useful layer on top of the primary linux project & tree.
Jenkins + a large enough test suite could do very nice automatic sanity
testing IMHO...that is what it is designed for (even if not to
automatically test pre-merge, but it could be adapted). Many pull
requests build on Linux, but not on MinGW, OSX, etc so just that would
be useful IMHO.
> Not a big deal to me, I never use GUI :)
>
> > Un-hardcode fee handling (anybody already working on this?)
>
> Has anyone actually come up with a good idea to code?
>
> This is a widely acknowledged problem, sure, but where are the good
> solutions, even on paper?
Sipa's stuff is quite good IMHO, it still has some problems left to
solve (like choosing minor details of the underlying priority algorithm)
but aside from those, I think it could work. I'm not sure if sipa wants
to just publish the stuff he did so far and let this list debate on the
remaining details and eventual implementation, or if he wanted to come
up with something complete before publishing, it up to him, but it is
doable.
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110811/58746a63/attachment.sig>;