Nils Schneider [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-09-02 to 2012-07-09
💬 Posted a total of 8 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 10:22:02

- reply

📅 Original date posted:2012-07-09
📝 Original message:I don't think that's a good idea as it can easily confuse or annoy users
when things move around. The ordering should be preserved as much as
possible so users can remember where they found a client they liked
(e.g. 2nd row, 1st column and screenshot with light and blue colors).
Making them search the entire page is inefficient and will just get
worse once there are many clients on the page (and I think that's the goal).
On 09.07.2012 17:54, Amir Taaki wrote:
> Took me a while, but finally got it working.
>
> Entries on the clients page are randomly ordered when the page is generated.
>
> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
>
> We should regenerate the page every 2 days. This gives fair exposure to all the clients listed.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:36:06

- reply

📅 Original date posted:2011-10-27
🗒️ Summary of this message: Suggestion to use a more reliable platform like a git repo for Bitcoin Improvement Proposals (BIPs) due to the unreliability of the wiki.
📝 Original message:Can we use a git repo or something more redundant for BIPs? They're
rather important and the wiki has been unreliable before.
On 27.10.2011 17:15, Amir Taaki wrote:
> Anybody know how to contact MT about getting it back online? I still
> haven't finished copy-editing the BIPs and need access to them since
> there's a new one to be added.
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning at Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:34:12

- reply

📅 Original date posted:2011-10-18
🗒️ Summary of this message: Proposal to use GitHub's Wiki feature for Bitcoin Improvement Proposals (BIPs) and appoint Amir as BIP editor. Discussions to be held on bitcoin-dev mailing list.
📝 Original message:> • I propose that BIPs be wiki pages, with a social convention that the
> Author gets final word if any editing wars break out.
That's a good idea. What about using GitHub's Wiki feature for BIPs?
They support MarkDown which is easy to read in text editors so we could
someday create a repo with all finalized BIPs. That's a lot easier than
importing a mediawiki dump. The last time en.bitcoin.it went down I
tried to setup a static mirror and that was nearly impossible without a
full LAMP stack. Also, BIPs should only contain images when absolutely
necessary.
> • If he's willing, I propose that Amir take the role of BIP editor.
ack
> • I think bitcoin is still too small to have a specialized
> "bitcoin-ideas" mailing list; I propose that new potential BIPs be
> discussed either here or on the bitcoin-dev mailing list.
ack

2023-06-07 02:33:02

- reply

📅 Original date posted:2011-10-22
🗒️ Summary of this message: Geir Harald Hansen offers to translate Bitcoin into Norwegian Bokmål if it is added to Transifex, a tool for coordinating translation efforts.
📝 Original message:I think it's possible to add it yourself. Just click on "add translation"
On 22.10.2011 14:26, Geir Harald Hansen wrote:
> On 22.10.2011 12:51, Nils Schneider wrote:
>>> And is anybody willing to take the job of coordinating translation
>>> efforts, figuring out if Transifex is a good tool to use, and writing
>>> some documentation to make it easy for people to create and submit new
>>> translations?
>>
>> I have exported all .ts to transifex.
>>
>> https://www.transifex.net/projects/p/bitcoin/resource/tx/
>
> If you add Norwegian Bokmål, I can do that one. Language code "nb".
>
> Regards,
> Geir Harald Hansen
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning at Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:32:56

- reply

📅 Original date posted:2011-10-22
🗒️ Summary of this message: Transifex is being used to coordinate translation efforts for Bitcoin. The process involves pulling updates and pushing them to GitHub.
📝 Original message:> And is anybody willing to take the job of coordinating translation
> efforts, figuring out if Transifex is a good tool to use, and writing
> some documentation to make it easy for people to create and submit new
> translations?
I have exported all .ts to transifex.
https://www.transifex.net/projects/p/bitcoin/resource/tx/
I'm now trying to figure out how to use it but it looks like
tx pull && git add src/qt/locale/* && git commit src/qt/locale/ && git push
will be all that's needed to push translation updates from transifex to
github.

2023-06-07 02:30:07

- reply

📅 Original date posted:2011-09-29
🗒️ Summary of this message: A pull request for deprecating midstate and hash1 in Bitcoin's code has been made to simplify the internal reference miner and remove dependencies on cryptopp.
📝 Original message:Yes, that's possible and what
https://github.com/bitcoin/bitcoin/pull/535 does. However, deprecating
midstate (and hash1) would allow for much cleaner code.
A pull request for marking midstate (and hash1) as deprecated can be
found at https://github.com/bitcoin/bitcoin/pull/538
On 29.09.2011 12:23, John Smith wrote:
> Nils,
>
> Sounds good. I'm also doubtful of depending on two crypto libraries when
> OpenSSL does perfectly well.
>
> However, losing compatibility with miners is not very nice. Is there
> really not a way to compute midstate with OpenSSL?
>
> JS
>
> On Mon, Sep 26, 2011 at 7:42 PM, Nils Schneider <nils at nilsschneider.net
> <mailto:nils at nilsschneider.net>> wrote:
>
> Hey,
>
> I'd like to simplify the internal reference miner and remove all
> dependencies on cryptopp (it's the only place we use cryptopp instead of
> OpenSSL).
>
> Unfortunately, cryptopp is also used to calculate getwork "midstate".
> This field is redundant and the miner could easily calculate it from the
> blockheader so I'd like to remove it.
>
> Any thoughts? Where should such a change should be announced so all
> miners can be upgraded?
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

2023-06-07 02:29:55

- reply

📅 Original date posted:2011-09-26
🗒️ Summary of this message: Proposal to simplify internal reference miner by removing dependencies on cryptopp and redundant getwork "midstate" calculation. Upgrade announcement for miners needed.
📝 Original message:Hey,
I'd like to simplify the internal reference miner and remove all
dependencies on cryptopp (it's the only place we use cryptopp instead of
OpenSSL).
Unfortunately, cryptopp is also used to calculate getwork "midstate".
This field is redundant and the miner could easily calculate it from the
blockheader so I'd like to remove it.
Any thoughts? Where should such a change should be announced so all
miners can be upgraded?

2023-06-07 02:20:32

- reply

📅 Original date posted:2011-09-02
🗒️ Summary of this message: MinorFs, a least authority based set of filesystems, could potentially secure Bitcoin wallets on servers, but wallet encryption is a simpler solution for end-users.
📝 Original message:MinorFs sounds like an interesting concept and but wallet encryption
(already being tested and close to release) is a simpler solution for
end-users.
Would MinorFs help securing the wallet on a server, maybe even a
(insecure) VPS?
Can it work without changes to Bitcoin? If not, what is the minimal
amount of changes needed?
Is there any guarantee it will never corrupt the wallet?
What would be the proper way to do backups?
On 02.09.2011 22:32, Rob Meijer wrote:
> Given that there was not a single response to my post, I gather there is
> no to little interest in an updated MinorFs that could be used by bitcoin
> on systems that support AppArmor (Ubuntu and OpenSuse).
>
> Nevertheless I've put down the initial set of specs for a rewrite of
> MinorFs for if anyone would like to comment on them to make a future match
> with Bitcoin more likely, I'm open to all sugestions:
>
> http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2
>
> On Fri, August 26, 2011 09:48, Rob Meijer wrote:
>> A few years ago I wrote a least authority based set of filesystems named
>> MinorFs that worked closely together with AppArmor (suse/ubuntu) to give '
>> pseudo persistent processes' their own private but decomposable and
>> delegatable piece of filesystem storage:
>>
>> http://www.linuxjournal.com/magazine/minorfs
>> http://www.capibara.com/blog/2011/05/25/taming-mutable-state-for-file-systems/
>>
>> Currently there is only one perfect fit for MinorFs and that's the stack
>> AppArmor/MinorFs/E-language-persistent-application. There are some close
>> fits like running ssh without a passphrase (
>> http://minorfs.polacanthus.net/wiki/Ssh_private_keys_without_passphrase )
>> but these require lots of manual fiddling by the user to get working. The
>> ssh trick would probably work with bitcoin, but as you can see from the
>> link above, it would be rather cumbersome.
>>
>> I am trying to get specs together for rewriting MinorFs (in Python) in a
>> way that would make it easy and natural for application developers that
>> want their application to be able to protect user data (like bitcoin
>> wallets) from mallware running under the same uid as that user.
>>
>> Currently minorfs granularity is hard fixed to that of the 'pseudo
>> persistent process', and that granularity is determined as described in
>> the following link:
>>
>> http://minorfs.polacanthus.net/wiki/Pseudo_persistent_process
>>
>> When using pseudo persistent processes, you basically end up with
>> file-system storage that follows almost all of the modeling principles of
>> the object capability model. This is great when designing a least
>> authority program from scratch and writing it in the (object capability)
>> e-language using its persistence facilities.
>>
>> Given however that I don't expect bitcoin, openssh, chrome, firefox, or
>> any other application that would benefit from what MinorFs provides to be
>> rewritten in E, it seems like the next version of MinorFs should give up
>> on the purity of its least authority model, and take an approach that
>> better suits common development languages and practices.
>>
>> With bitcoin being a project that could benefit most from what MinorFs has
>> to offer, I would like to ask bitcoin developers to think about what
>> attributes from the current granularity level (pseudo persistent process)
>> should be kept, what attributes should be dropped, and what properties
>> should be added to arrive at an 'id' that is the best fit for granularity
>> of persistent private storage for bitcoin.
>>
>> I really want to accommodate bitcoin developer needs in this, so all input
>> that helps me help you guys to get the next MinorFs version to accommodate
>> your needs to a level that code to use MinorFs where available can be
>> added to bitcoin, would be extremely welcome.
>>
>> Let me know what you think,
>>
>> Rob
>>
>>
>> ------------------------------------------------------------------------------
>> EMC VNX: the world's simplest storage, starting under $10K
>> The only unified storage solution that offers unified management
>> Up to 160% more powerful than alternatives and 25% more efficient.
>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>