[Bitcoin-development] Is SourceForge still trustworthy enough to host this list?
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. signature.asc Description: This is a digitally signed message part. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Core 0.9.4 not on bitcoin.org?
Why is that? Also, is it correct that there wasn't a release candidate before the release? Sounds dangerous to me. signature.asc Description: This is a digitally signed message part. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
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 signature.asc Description: This is a digitally signed message part. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Something people are forgetting about the Gentoo / Luke-jr censorship issue
Hey folks, FYI the issue is that Luke-Jr wants to include code which can censor stuff like SatoshiDice transactions because he thinks they are denial of service: https://bugs.gentoo.org/show_bug.cgi?id=524512 While everyone is jumping on the neutrality Bitcoin should have, you're forgetting that there are also *legal* implications: The *technical ability'* to filter certain types of network traffic can cause you to be legally liable to *USE* it to filter illegal stuff. So even if the filter code is disabled by default, it can put Bitcoin users in legal danger: Law enforcement can try to force them to use it. This for sure depends on the country you are living in, but in general I think it can be agreed that it will be a lot easier to defend a my node relays everything uncensored policy against law enforcement if you wouldn't even have the technical ability to filter stuff because the code just cannot do it anyway. So please do not even include this code as disabled, and if possible do not even write or publish it :) Also, as I don't have a Gentoo bugtracker account, can someone please add this comment there? Thanks Gretings, xor - a developer of https://freenetproject.org/ signature.asc Description: This is a digitally signed message part. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote: Encryption is of little value if you may deduce the same information by observing packet sizes and timings. Instead of spawning a discussion whether this aspect is a reason to NOT encrypt, you should do the obvious: Fix that as well. X being broken is not a reason for not fixing Y. Pad the then encrypted packets with random bytes. The fact that they are encrypted makes them look like random data already, so the padding will not be distinguishable from the rest. Also, add some random bias to their timing. And besides: It would be nice if everyone could acknowledge that making Bitcoin as anonymous as possible is a natural desire. People demanding you to do this is bound to happen over and over again until you do it :) So just get on with it instead of postponing it due to doubts. There is Tor, there is Freenet, and there are other anonymous P2P networks, and they can help you do get it done - the said problems have been well-known there for quite some time and people have thought about how to solve them. Greetings, xor, a developer of https://freenetproject.org signature.asc Description: This is a digitally signed message part. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering github
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 signature.asc Description: This is a digitally signed message part. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties
On Thursday, August 07, 2014 12:22:31 AM Tim Ruffing wrote: - Decentralization / no third party: There is no (trusted or untrusted) third party in a run of the protocol. (Still, as in all mixing solutions, users need some way to gather together before they can run the protocol. This can be done via a P2P protocol if a decentralized solution is desired also for this step.) [...] http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/ for a technical overview. I think the description at your website leaves out the truly interesting part: How do you decentralize this securely? - How do Alice, Bob, Charlie and Dave communicate, i.e. which network is used for communication and how? - How does Alice know that Bob, Charlie and Dave are not the same person? (= how do you prevent a Sybil attack?) Because thats the real problem with mixing it seems - ensuring that your mixing partners are actually 100 people and not just 1 attacker. There are probably many mixing algorithms which work if you solve that problem, but I don't see how you offer a solution for it :( signature.asc Description: This is a digitally signed message part. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Lets discuss what to do if SHA256d is actually broken
-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- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
