Re: [Bitcoin-development] Reconsidering github
On Wed, Aug 20, 2014 at 08:24:33AM +0200, Wladimir wrote: On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes ho...@hozed.org wrote: If bitcoin wants to become irrelevant, then by all means, continue to depend on github and all the unknown attack surface it exposes. Those of us that do run our own servers will migrate to higher quality alternatives. So that means you're volunteering to run a web-accessible mirror of the bitcoin repositories? Wladimir http://bitspjoule.org/hg/upstream/bitcoin I guess I should update it more than every 6 months and then the updates won't take so long. It would also go a lot faster if I had a couple of dedicated servers, but that won't happen until I sell someone a support contract for crypto-commodities trading. I figure a bitcoin a month should support the hardware, 24x7 monitoring, and maybe a couple of full nodes running on the servers as well. And to pick up from another comment on this thread if you don't understand some of the differences between git and mercurial, or how to set up servers that pull from git and mirror to mercurial, you will have a lot harder time tracking down and removing malicous code that could get injected if someone gets root on a Github server. It is also a very usefull excercise in distributed systems design to understand how distributed revision control systems in theory converge to a coherent global state, and what is similiar or different to Bitcoin's global consensus model of what the balance of every bitcoin address is. -- 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
Gerrit is free if you can afford the admin(s) to maintain it. http://code.google.com/p/gerrit/wiki/ShowCases And yes, I'm volunteering to get paid to be the admin, especially if you want a 'painless' log in with a github account feature, because it will be very painful for me to unroll the damage if github is compromised. My preference would be that we use the same ECDSA keys we secure our bitcoins with to secure our access to the code review and source control systems. On Wed, Aug 20, 2014 at 04:16:11PM +0200, Mike Hearn wrote: If github were to be abandoned for anything, it'd make sense to move code review and bug tracking elsewhere. GitHub does a reasonably good job of hosting git repositories. It kind of sucks at code review and the issue tracker is rudimentary at best. These days you can do log in with my github account so if done well, it'd not have to be very painful. JetBrains make great stuff and they have a code review and repository exploration tool called Upsource in development, which should come out soon. I think it's proprietary but that would be no different to github, and it's designed for self hosting. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- 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 Fri, Aug 22, 2014 at 09:20:11PM +0200, xor wrote: 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 This is why I clone git to mercurial, which is generally designed around the assumption that history is immutable. You can't rewrite blockchain history, and we should not be re-writing (rebasing) commit history either. The problem with github is it's too tempting to look at the *web page*, which is NOT pgp-signed, and hit the 'approve' button when you might have someone in the middle approving an unsigned changeset because you're in a hurry to get the latest new critical OpenSSL 0day security patch build released. We need multiple redundant 'master' repositories run by different people in different jurisdictions that get updated on different schedules, and have all of these people pay attention to operational security, and not just outsource it all to github because it's convenient. There's no reason to *stop* using github, cause it *is* easy... but you want to have multiple review of *the actual code*, not just signatures and see if the changes really do make sense. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- 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] Proposal: Encrypt bitcoin messages
I think it's a little disingenuous to talk about encrypting the P2P protocol as a security improvement, when all the organized crime agencies need to do is borrow a Fedex/UPS truck and deliver some laptops to Github employees and they can insert whatever monitoring/0-day they want. Encryption is complicated stuff to actually **get right**, and the more stuff you throw crypto around, the more likely it is you'll get a Heartbleed 0-day If you want to increase security, make it simpler. I'm not even sure it can be easily simplified... how could you separate the P2P network transport from the core blockchain functionality? On Wed, Aug 20, 2014 at 04:37:24PM +0200, Mike Hearn wrote: I would be very happy if we upgraded the P2P protocol with MAC keys and a simple home grown encryption layer, because: 1. It's practically guaranteed that 5-eyes intelligence agencies are either systematically deanonymising Bitcoin users already (linking transactions to real world identities) or close to succeeding. Peter is correct. Given the way their infrastructure works, encrypting link level traffic would significantly raise the bar to such attacks. Quite possibly to the level where it's deemed unprofitable to continue. 2. Tor is not a complete solution. The most interesting links to monitor are those from SPV clients connecting to Core nodes. Whilst Java SPV clients have the nice option of an easy bundled Tor client (er, once we fix the last bugs) clients that are not based on bitcoinj would have to use the full-blown Tor client, which is not only a PITA to bundle as Tor is not at all library-fied, but is a giant pile of C which is almost certainly exploitable. Even if it runs in a separate address space, for many platforms this is insufficient as a compromised Tor client could then go ahead and compromise your wallet app too. Implementing a full Tor client is not a reasonable thing to ask of a wallet developer, but doing HMAC checks and a simple ECDH exchange + AES would be quite realistic. -- 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 -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- 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 Sat, Aug 23, 2014 at 8:17 AM, Troy Benjegerdes ho...@hozed.org wrote: On Fri, Aug 22, 2014 at 09:20:11PM +0200, xor wrote: 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: Note that we're generally aiming (though not yet enforcing) to have merges done through the github-merge tool, which performs the merge locally, shows the resulting diff, compares it with the merge done by github, and GnuPG signs it. That allows using github as easy-access mechanism for people to contribute and inspect, while having a higher security standard for the actual changes done to master. -- Pieter -- 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] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)
Hi Mike, thanks for your assessment. Please find my replies in-line: Misbehaving addresses can have their connecting difficulty scaled up, which should make it uneconomic to try to DoS the usage of Tor exit nodes for connecting to Bitcoin. You can't solve DoS by requiring all clients to do complicated work, Since when? This has been a recognized approach since people called it hashcash ([1] - before cryptocurrencies were even invented). I hear your concerns, but even then, I would see the PoW-based approach as an improvement to today's situations. To be clear, I do not propose to have _all_ clients do complicated work. Just those using an address which has been misbehaving. Right now, they cannot connect at all, no matter how much resources they dedicate towards doing so. all that means is that weak clients (like users mobile phones and tablets) are successfully DoSd whereas the attackers botnet of stolen computers sit there solving PoWs. The way I had it in mind, well-behaved clients on an address used by attackers would have more effort to connect because of the PoW, but after that, they can stay connected. The attacker also has to put more effort into connecting, and after sending malformed messages, gets disconnected. So, the attacker would have to perform much more PoW computations in order to keep up his attack. The correct way to solve DoS is by having work prioritisation and queueing mechanisms, then finding ways to distinguish good clients from bad clients. Doing this whilst preserving privacy is hard. Long term the only way to solve it may be to require clients to present some kind of cookie during resource exhaustion events that prove they've been around for a while, thus allowing them to jump the queue. Exactly. Not every user may like to have a cookie by which an observer might get the chance to even link his connection to his previous connections, thereby allowing the discussed deanonymization technique to get even more effective. Maybe having both options would be even better: In case of an attack, those able to solve the anti-DoS PoW can still connect (just maybe slower). Those who wish to run a weak client can choose to sacrifice privacy for connectivity and keep a cookie for connecting. Best regards, Isidor [1] http://www.hashcash.org/papers/hashcash.pdf -- 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 23 August 2014 12:38, Pieter Wuille pieter.wui...@gmail.com wrote: That allows using github as easy-access mechanism for people to contribute and inspect, while having a higher security standard for the actual changes done to master. I'd also like to point out the obvious: git uses the previous hash as part of the formula to generate the current commit hash thus tampering with history while possible would be instantly noticed because we all have copies of the repository. Tampering would be completely evident (pushes would fail for a start, and even simple merges would bork). It's just not possible to tamper with the repository without it being discovered, even with collusion (or strong arming) of github. The social benefits of github make it idea for open source projects that want community participation. The barrier to entry is low. The only weak spot of github is the releases section, but since we don't actually distribute Bitcoin from github the point is moot. I think github haters fail to see the vast benefits of a social hub like github. Their issue tracker may not be as sophisticated, it serves well and the project is extremely productive. Don't shoot yourself in the foot - a move away from github would be a disaster for the project. When you look at the attack surface of using github, it's pretty small and would not go unnoticed, thus nullifying concern. -- 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] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)
Since when? This has been a recognized approach since people called it hashcash ([1] - before cryptocurrencies were even invented). I only know of one site that worked the way you propose: TicketMaster, a long time ago. They used it as a less harsh form of blocking for IPs that they strongly suspected were bots, which is what you suggest indeed. But 99% of the hard work of that system was in scoring the connections. The actual PoW part didn't work that great because bots have much more patience than humans do. Other sites also use proofs of work, but they're CAPTCHAs i.e. human PoWs. And unfortunately those don't work very well these days either :( To be clear, I do not propose to have _all_ clients do complicated work. Just those using an address which has been misbehaving. Yes, I understand, but then you're back to scoring clients - the hard part - and the only question is do you slow down that client by sticking them at the bottom of a work queue or by requiring them to solve a difficult PoW. The best approach is the first one because that scales naturally you don't have to define some notion of misbehaviour, you just prioritise amongst clients. The current notion of misbehaviour is only somewhat useful. It's easy to classify reasonable behaviour as harmful and shoot yourself in the foot. We managed this at least once back in 2010 when we actually released a version of Bitcoin that interpreted a normal request to serve the block chain as a DoS attack! It couldn't serve the chain at all! Additionally many things that can be interpreted as an attack like sending a message with a bad signature can also be caused just by mistakes, or version skew during software upgrades. So it's very tricky to get this right. That's important because one quite common way big sites suffer DoS attacks is by accidentally having real users create a DoS attack by e.g. pushing a bad software update, or by having sudden and unexpected press-driven growth, etc. You really don't want to force users to sit around waiting and wasting battery. It's better to serve as many requests as you can up to your absolute limit and try to ensure as many of them as possible are good. Exactly. Not every user may like to have a cookie by which an observer might get the chance to even link his connection to his previous connections, thereby allowing the discussed deanonymization technique to get even more effective. I doubt it matters. Any DoS attack that's powerful enough to use up most of the networks resources is probably being driven by a botnet of some kind, and *all* legitimate users will lose in an even fight against a botnet. Cookies can be somewhat anonymized. For example a cookie that is merely a signature over a timestamp of some kind (doesn't have to be an secp256k1 signature) can be normalised to the day or week. So you can prove you've been using Bitcoin for say 3 years but it doesn't pin you down precisely. This isn't perfect: attackers can and do age accounts before preparing for abuse. Proof of UTXO is another way to rank users. If you're richer you're presumably more important for the network to process than poor people. However you end up back at a CPU imbalance. PoW can possibly play a role here to even it out: the cost of submitting a UTXO proof should be at least equal to the cost of verifying the signature, but that is a PoW small enough that users would not notice. -- 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 Sat, Aug 23, 2014 at 1:38 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Note that we're generally aiming (though not yet enforcing) to have merges done through the github-merge tool, which performs the merge locally, shows the resulting diff, compares it with the merge done by github, and GnuPG signs it. Indeed. I always use that look at and test and the merges locally before pushing them. I never use the github merge button. I'd recommend other people to do so as well - and as can be seen with `git log --show-signature` it's common practice. For browsing git history locally I find gitk to be a useful tool. I'd absolutely encourage for more people to review code changes. Even better if a few people do this through local tooling instead of the web page. But my gut feeling is that hosting the code on github results in many more eyes on the code overall than would be when requiring *everyone* to use local tools. It's easy to let paranoia get in the way of actual effectiveness. Wladimir -- 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] 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] Proposal: Encrypt bitcoin messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/23/2014 04:17 PM, xor wrote: 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. The packet size and timing issue will become less of an issue as the network grows anyway. One transaction inserted into a 3 transaction-per-second encrypted stream is more obvious than the same transaction inserted into a 100 or 1000 TPS stream. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJT+MZWAAoJEMP3uyY4RQ21tDoH/0SPYQcUkYJcuDhTkJCFWdyx ob3H7ITEcqD0UZ3n3QHdxHfCDlP2srL0EcfjbNceRX5inP47jdoGj7uIkY/NRHQ0 4J2WCIrcu1Bj3ZxXG59PtfUzMjxhMGDMSk5eE+6BjVQILrkxxrqSpVjykfoq5s6Y EBdT2Pf4djQ5k2fQ2PX1dTt5iCvFh0ufq3McrYsciRzguRwlelw1W34tPBqGSv0n LScgvqYUTGC7otUdA5K/3WBq6SSo7E13hJxiLKQZMQ4CPpSlsiAhI5fuhl0OBljC hCtS+eugFmvMICQt0ELds++nnA5WN/Yjx1WIrnLA1EmNiAkS9RSEVMcyab0TtdI= =0sjO -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- 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 Sat, Aug 23, 2014 at 10:32:15AM -0400, Peter Todd wrote: On Sat, Aug 23, 2014 at 01:17:01AM -0500, Troy Benjegerdes wrote: This is why I clone git to mercurial, which is generally designed around the assumption that history is immutable. You can't rewrite blockchain history, and we should not be re-writing (rebasing) commit history either. Git commits serve two purposes: recording public history and communication. While for the purpose of recording history immutable commits make sense, for the purpose of communicating to other developers what changes should be added to that history you *do* want the mutable commits that git's rebase functionality supports. Much like how university math classes essentially never teach calculus in the order it was developed, it is rare indeed for the way you happened to develop some functionality to be the best sequence of changes for other developers to understand why and what is being changed. Anyway, just because mercurial is designed around the assumption that commit history is immutable doesn't mean it actually is; an attacker can fake a series of mercurial commits just as easily as they can git commits. The only thing that protects against history rewriting is signed commits and timestamps. What I would really like is a frontend and/or integration to Git/Mercurial that uses Bitcoin transactions *as* the signature, which has the nice side effect of providing timestamps backed by the full faith and credit of a billion dollar blockchain. So what is the best way for me to stick both a git *and* a mercurial identity hash into a bitcoin transaction? (which leads to point 2 below) The problem with github is it's too tempting to look at the *web page*, which is NOT pgp-signed, and hit the 'approve' button when you might have someone in the middle approving an unsigned changeset because you're in a hurry to get the latest new critical OpenSSL 0day security patch build released. We need multiple redundant 'master' repositories run by different people in different jurisdictions that get updated on different schedules, and have all of these people pay attention to operational security, and not just outsource it all to github because it's convenient. The easiest and most useful way to achieve that would be to have a formal program of code review, perhaps on a per-release basis, that reviewed the diffs between the previous release and the new one. Master repos in this scenario are simply copies of the master master repo that someone has manually verified and signed-off on, with of course a PGP signature. If you feel like volunteering to maintain one of these repos, you may find my Litecoin v0.8.3.7 audit report to be a useful template: https://bitcointalk.org/index.php?topic=265582.0 I'm not interested in volunteer, I'm interested in getting paid, and the best way I believe I can accomplish that is use *my* bitcoin address in a signature-transaction of the code I've reviewed. What is the advantage of PGP? Far more people have ECDSA public-private keys than PGP keys. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- 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] Proposal: Encrypt bitcoin messages
On Sat, Aug 23, 2014 at 04:50:30PM +, Justus Ranvier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/23/2014 04:17 PM, xor wrote: 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. The packet size and timing issue will become less of an issue as the network grows anyway. One transaction inserted into a 3 transaction-per-second encrypted stream is more obvious than the same transaction inserted into a 100 or 1000 TPS stream. The requirement for anonymity and privacy is lawyers and a Bitlicense. If you want privacy and anonymity, then do high-frequency trading on a centralized exchange, and if you want to go over-the-top, run some arbitrage bots as well, and hide in the millions of transactions per second that go on. But make sure you get a Bitlicense and have a good securities lawyer. Trying to solve a legal/legislative/social problem with more crypto is only going to serve the people who created the legal/legislative/social problem in the first place, because they can hire a hacker who will find a misplaced (} in your crypto code, and all the work you did to encrypt wire protocols becomes silently worthless. -- 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] Proposal: Encrypt bitcoin messages
Not to mention encrypting basically non-sensitive inter-node traffic is almost completely worthless in providing anonymity anyway... Recall that P2P connections carry Bloom filters too, which are not public information. -- 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] Proposal: Encrypt bitcoin messages
On Saturday, August 23, 2014 6:44:15 PM Mike Hearn wrote: Not to mention encrypting basically non-sensitive inter-node traffic is almost completely worthless in providing anonymity anyway... Recall that P2P connections carry Bloom filters too, which are not public information. As soon as you tell it to an unknown/public peer, it is public information. -- 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
I want go give a bit of an outsiders perspective. I thoroughly understand the concepts of bitcoin and am a professional programmer, but have never taken the time to compile my own copy of bitcoin core. I have looked at the pull requests on Github many times. I have cloned the repo to my own computer, but haven't really used that to do much. I find Github very easy to use, and (to me) it has the lowest bar to get more eyes passively looking at the code. As a security guy, I appreciate the extra time and effort that goes into signing commits and merges even if I have not personally verified the signatures. I would like to see bitcoin core continue to use github, but have no objection to additional mirrors of the repo being hosted on different sites. -- 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 Sat, Aug 23, 2014 at 1:36 PM, Paul Rabahy prab...@gmail.com wrote: I want go give a bit of an outsiders perspective. I thoroughly understand the concepts of bitcoin and am a professional programmer, but have never taken the time to compile my own copy of bitcoin core. I have looked at the pull requests on Github many times. I have cloned the repo to my own computer, but haven't really used that to do much. I find Github very easy to use, and (to me) it has the lowest bar to get more eyes passively looking at the code. As a security guy, I appreciate the extra time and effort that goes into signing commits and merges even if I have not personally verified the signatures. I would like to see bitcoin core continue to use github, but have no objection to additional mirrors of the repo being hosted on different sites. Nothing suggested here would ever remove the ability to go and explore and read the changes just as you're doing so. Already the way it works is that our local repositories are authoritative for each of us. (Git itself is a decentralized system regardless of github's efforts to make it look otherwise). -- 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 Sat, Aug 23, 2014 at 12:44:14PM -0500, Troy Benjegerdes wrote: What I would really like is a frontend and/or integration to Git/Mercurial that uses Bitcoin transactions *as* the signature, which has the nice side effect of providing timestamps backed by the full faith and credit of a billion dollar blockchain. So what is the best way for me to stick both a git *and* a mercurial identity hash into a bitcoin transaction? (which leads to point 2 below) A bitcoin transaction can't by itself serve as a signature, as there isn't any way to link the transaction to what you actually care about - a human being - without additional infrastructure. You may find it helpful to reflect back upon your 2nd and 3rd year courses on post-modernism and semiotics: Is a keypair in a public key cryptography system what is being signified, or is it merely a (posssibly false) signifier? If you just want to timestamp a git commit you can timestamp it in the Bitcoin blockchain. I have the code to do so in my python-bitcoinlib: examples/timestamp.py git commit To check timestamps the following should work, although I haven't tried: bitcoind searchrawtransactions git commit You do need the searchrawtransactions patch. I've personally timestamped most of the git tags for releases this way. If you feel like volunteering to maintain one of these repos, you may find my Litecoin v0.8.3.7 audit report to be a useful template: https://bitcointalk.org/index.php?topic=265582.0 I'm not interested in volunteer, I'm interested in getting paid, and the best way I believe I can accomplish that is use *my* bitcoin address in a signature-transaction of the code I've reviewed. What is the advantage of PGP? Far more people have ECDSA public-private keys than PGP keys. PGP of course has vast amounts of identity infrastructure already developed for it, infrastructure that simply doesn't exist for Bitcoin addresses In any case you'll be happy to know that secp256k1 has been added to the GPG development branch, which means you can sign your code with a ECDSA key corresponding to a Bitcoin address if you wish too. -- 'peter'[:-1]@petertodd.org 06fb87cb8ec6e0981b134953f1916c513f7210b534a94b8b signature.asc Description: Digital signature -- 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] Proposal: Encrypt bitcoin messages
On Sat, Aug 23, 2014 at 07:02:55PM +, Luke Dashjr wrote: On Saturday, August 23, 2014 6:44:15 PM Mike Hearn wrote: Not to mention encrypting basically non-sensitive inter-node traffic is almost completely worthless in providing anonymity anyway... Recall that P2P connections carry Bloom filters too, which are not public information. As soon as you tell it to an unknown/public peer, it is public information. Mike is correct here: It *might* be public information, and probably won't be. We already can give weak assurance that it probably won't be against many weaker attackers, simply because getting lots of IP addresses is moderately expensive, and in the future additional methods will be developed and deployed. -- 'peter'[:-1]@petertodd.org 239344fc532bbad8a679e3fc30e8900772523a10c4720a0c signature.asc Description: Digital signature -- 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
