<unnamed>

Public Key

npub14a7v3r4ppfy007s0tk2h0ujh38h9x4t6jyrndev9qmmazd2vrsvqxg6tv3

Profile Code

nprofile1qqs27lxg36ss5j8hlg84m9th7ftcnmjn24afzpekukzsda73x4xpcxqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3samnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kqzrthwden5te0dehhxtnvdakqlhg0ym

Publishing to

relay.damus.io

relay.snort.social

nos.lol

Last Notes

2023-06-07 15:37:10 UTC

- reply

📅 Original date posted:2015-06-10
📝 Original message:http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/
TL;DR:
> In 2013, GIMP’s developers pulled the GIMP Windows downloads from
> SourceForge. SourceForge was full of misleading advertisements
> masquerading as “Download” buttons — something that’s a problem all over
> the web.
[...]
> In 2015, SourceForge pushed back. Considering the old GIMP account on
> SourceForge “abandoned,” they took control over it, locking out the
> original maintainer. They then put GIMP downloads back up on SourceForge,
> wrapped in SourceForge’s own junkware-filled installer.
-------------- 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/20150610/10e90e6d/attachment.sig>

2023-06-07 15:29:24 UTC

- reply

📅 Original date posted:2015-02-01
📝 Original message:Why is that?
Also, is it correct that there wasn't a release candidate before the release?
Sounds dangerous to me.
-------------- 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/20150201/33933d24/attachment.sig>

2023-06-07 15:26:32 UTC

- reply

📅 Original date posted:2014-10-19
📝 Original message:On Wednesday, October 15, 2014 10:29:43 AM Wladimir wrote:
> B) I also think it makes sense to move the BIP discussion (both about
> the BIP process and individual BIPs) to a separate mailing list.
>
> bitcoin-development currently has a dual function: discussion of
> Bitcoin Core implementation concerns, as well as global changes to
> Bitcoin (in the form of BIPs).
>
> This makes the list too busy for some people, but it is critical that
> everyone writing a Bitcoin node or client is up-to-date with proposals
> and can comment on them.
I joined the list when Bitcoin was already in the 10-billions of market
capitalization, and it actually really surprised me how low the traffic is here
given the importance of Bitcoin.
So as a random stranger to the project, I would vote against that if I was
allowed to. There really should be *more* discussion here, and splitting the
list up won't help with that.
Greetings
-------------- 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/20141019/3bafc443/attachment.sig>

2023-06-07 15:25:30 UTC

- reply

📅 Original date posted:2014-08-22
📝 Original message:On Tuesday, August 19, 2014 08:02:37 AM Jeff Garzik wrote:
> It would be nice if the issues and git repo for Bitcoin Core were not
> on such a centralized service as github, nice and convenient as it is.
Assuming there is a problem with that usually is caused by using Git the wrong
way or not knowing its capabilities. Nobody can modify / insert a commit
before a GnuPG signed commit / tag without breaking the signature.
More detail at the bottom at [1], I am sparing you this here because I suspect
you already know it and there is something more important I want to stress:
Bitcoin has currently 4132 forks on Github. This means that you can get
contributions by pull requests from 4132 developers. That is a HUGE amount,
and you shouldn't ditch that due to not using all features of git :)
To get a grasp of how much that is: When you search projects with more than
4100 forks, there are only 32 of them!
You are one of the top open source projects, and you should be grateful for
that and keep Github up so the other people can send you pull requests with
their improvements :) Volunteer contributions need to be honored and made as
easy as possible, for people are investing their personal time.
Greetings and thanks for your work,
xor, one developer of https://freenetproject.org
[1] If you GPG-sign a commit / tag, you sign its hash, including the hash of
the previous commit. So is a chain of hashes and thus of trust from all
commits up to what is signed. It's pretty similar to the blockchain actually
:)
So Github cannot modify anything. If they did, the head of the hash-chain
would change, and thus the signature would break. Git would notify people
about that when they pull.
Of course people can still ignore that warning and let Github rewrite their
Git history. But people who aren't educated about this shouldn't be release
managers. They should not even have push access to your main repository, they
should only be sending pull requests. Thats is where the decentralization of
Git is: In the pull-requests. The people who deal with them should verify tag
and possibly even commit signatures carefully, and not accept anything which
is not signed. Also, before deploying a binary, the very same commit which is
going to become a binary has to be given a signed tag by the release manager,
and by everyone who reviews the code. The person who deploys the actual binary
needs to verify that signature.
There is an article which elaborates on some of the ways you have to ensure
Github doesn't insert malicious code - but please read it with care, some of
its recommendations are bad, especially the part where its about rebasing
because that DOES rewrite history which is what you want to prevent:
http://mikegerwitz.com/papers/git-horror-story
-------------- 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/20140822/5f63b114/attachment.sig>

2023-06-07 15:22:13 UTC

- reply

📅 Original date posted:2014-06-03
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
I thought a lot about the worst case scenario of SHA256d being broken in a way
which could be abused to
A) reduce the work of mining a block by some significant amount
B) reduce the work of mining a block to zero, i.e. allow instant mining.
Bitcoin needs to be prepared for this as any hash function has a limited
lifetime. Usually crypto stuff is not completely broken instantly by new
attacks but gradually. For example first the attack difficulty is reduced from
2^128 to 2^100, then 2^64, etc.
This would make scenario A more likely.
Now while B sounds more dangerous, I think in fact A is:
Consider how A would happen in real life: Someone publishes a paper of a
theoretical reduction of SHA256d attacks to 2^96 bit. Mathematicians will
consider this as a serious attack and create a lot of riot.
If no plan is made early enough, as in now, the Bitcoin Core team might then
probably want to just do the easiest approach of replacing the hash function
after a certain block number, i.e. a hard fork.
But what about the Bitcoin miners, those who need to actually accept a change
of mining algorithm which renders their hardware which cost MILLIONS
completely worthless?
Over the years they have gotten used to exponential growth of the Bitcoin
networks hashrate, and therefore exponential devaluation of their mining
hardware. Even if the attack on SHA256d causes a significant growth of
difficulty, the miners will not *believe* that it is an actual attack on SHA256d
- - maybe it is just some new large mining operation? They are used to this
happening! Why should they believe this and switch to a new hash function
which requires completely new hardware and therefore costs them millions?
They will just keep mining SHA256d. Thats why this is more dangerous, because
changing the hash funciton won't be accepted by the miners even though it is
broken.
Something smarter needs to be thought of.
Now I must admit that I am not good at cryptography at all, but I had the
following idea: Use the altcoin concept of having multiple hash functions in a
chain. If SHA256d is broken, it is chained with a new hash function.
Thereby, people who want to mine the new replacement hash function still will
need ASICs which can solve the old SHA proof of work. So existing ASIC owners
can amend their code to do SHA256d using the ASIC, and then the second hash
function using a general purpose CPU.
This would also allow a smooth migration of difficulty - I don't even know how
difficulty would react with the naive approach of just replacing SHA with
something else: It would probably be an unsolvable problem to define new rules
to make it decrease enough so new blocks can actually be mined by the now
several orders of magnitude slower CPU-only mining community but still be high
enough to be able to deal with the fact that millions of people will try their
luck with mining at the release date.
While this sounds simple in theory, it might be a lot of work to implement, so
you guys might want to take precautions for it soon :)
Greetings,
xor - A Freenet project developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBCAAGBQJTjU9DAAoJEMtmZ+8tjWt5pNEP/2460eHu7ujrUSxinJXY7+wF
E759/NcpNuakqu4NsS3ndi8lSiVIeixiOWZxPwLYkzC0pgPd5JrK5hdrYewsgreL
Ltkh6LKB4YZLYrV3jm62ZPMTzCopYQ1l872xbN3PJQJoXhEp4fKu99++LDzVg9Gk
n7rvrk6Iy/nSsZ1IMANpKghbU8/Gtn6ppCJv9rxRE//CZdTso1tTyOXXkEEMTHcV
y/iv6CHXtTXPvOgEgciU0oCPq0NOUKdIAOD//ybcKzncOoHSmwr1rZdreCTH6/Ek
9uwq/HaQnseHPrq9qrIkIKrZDlnjKu7Tqw1BlbyBeCrWdJPCeDJg2kyCXgTvIzFD
oXwZ6r16tb2QPR4ByyO1lZy9G2Pp26thk12BnadnPYTf1rMvsY15BjfUrCU9ppt/
YpFAZSFlXUGOuOBKUznUeO8U1bXJylcTTnyER/cudOpcKR8Jt9l5tfm5LTHCB6Q2
Tjmvsmd0BzwafLEhHD5FHoTZFNVdXWvEUO/w4I/2UWTS7CacbE1qk0rVpsF/4L1K
/oFVnZIUKqsm5mMMb6WTQq+MjP2TF/eAAwm2UtFYmj0FVML9HBNwyiAc5UKwnD4Y
Yq3Pl5QfRobwu6pgT3zO7vK+saOl8sePWbU8Skj41OTEDrJM4QIQGAqs1U8xke8+
YnUYiyzreJ8ofHhNBs4/
=dkuk
-----END PGP SIGNATURE-----