* [Bitcoin-development] Reconsidering github
@ 2014-08-19 12:02 Jeff Garzik
2014-08-19 12:28 ` Dāvis Mosāns
` (4 more replies)
0 siblings, 5 replies; 25+ messages in thread
From: Jeff Garzik @ 2014-08-19 12:02 UTC (permalink / raw)
To: Bitcoin Dev
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.
To that end, I note that Linux does its own git repo, and now requires
2FA: http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication
As a first step, one possibility is putting the primary repo on
bitcoin.org somewhere, and simply mirroring that to github for each
push.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [Bitcoin-development] Reconsidering github 2014-08-19 12:02 [Bitcoin-development] Reconsidering github Jeff Garzik @ 2014-08-19 12:28 ` Dāvis Mosāns 2014-08-19 14:58 ` Wladimir ` (3 subsequent siblings) 4 siblings, 0 replies; 25+ messages in thread From: Dāvis Mosāns @ 2014-08-19 12:28 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1116 bytes --] There's actually a pretty good alternative - GitLab <https://about.gitlab.com/> it's open source, self-hosted and provides similar features to GitHub 2014-08-19 15:02 GMT+03:00 Jeff Garzik <jgarzik@bitpay•com>: > 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. > > To that end, I note that Linux does its own git repo, and now requires > 2FA: > http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication > > As a first step, one possibility is putting the primary repo on > bitcoin.org somewhere, and simply mirroring that to github for each > push. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 1990 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-19 12:02 [Bitcoin-development] Reconsidering github Jeff Garzik 2014-08-19 12:28 ` Dāvis Mosāns @ 2014-08-19 14:58 ` Wladimir 2014-08-20 1:26 ` Troy Benjegerdes 2014-08-30 3:33 ` Odinn Cyberguerrilla 2014-08-19 15:44 ` Bryan Bishop ` (2 subsequent siblings) 4 siblings, 2 replies; 25+ messages in thread From: Wladimir @ 2014-08-19 14:58 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik <jgarzik@bitpay•com> 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. Despite my complaining about github, I don't like the idea of moving somewhere else. The current way of working - to use github for storing the tree, and use a custom script for signing+merging - is fine with me. Github has a low barrier to contribution. Almost every open source developer already has a github account. Switching to something self-hosted makes it more difficult for people to contribute. Plus if we have to take the hosting upon ourselves, we have to handle sysadmin work ourselves as well. That's not a good use of the limited manpower available. Also it will be a lot of work to migrate over all the current issues and pulls. I don't look forward to that. I don't see the point of this, sorry. Wladimir ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-19 14:58 ` Wladimir @ 2014-08-20 1:26 ` Troy Benjegerdes 2014-08-20 1:34 ` Gregory Maxwell 2014-08-20 6:24 ` Wladimir 2014-08-30 3:33 ` Odinn Cyberguerrilla 1 sibling, 2 replies; 25+ messages in thread From: Troy Benjegerdes @ 2014-08-20 1:26 UTC (permalink / raw) To: Wladimir; +Cc: Bitcoin Dev On Tue, Aug 19, 2014 at 04:58:48PM +0200, Wladimir wrote: > On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik <jgarzik@bitpay•com> 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. > > Despite my complaining about github, I don't like the idea of moving > somewhere else. The current way of working - to use github for storing > the tree, and use a custom script for signing+merging - is fine with > me. > > Github has a low barrier to contribution. Almost every open source > developer already has a github account. Switching to something > self-hosted makes it more difficult for people to contribute. > > Plus if we have to take the hosting upon ourselves, we have to handle > sysadmin work ourselves as well. That's not a good use of the limited > manpower available. > > Also it will be a lot of work to migrate over all the current issues > and pulls. I don't look forward to that. I don't see the point of > this, sorry. > > Wladimir If a project cannot be organized enough to run its own hosting/web presense/ counterintelligence/security that starts with installing an OS and patching kernels, then it is really not wise for me to trust my financial future to software written by such a group. There is a great deal of 'work' that is really quite pointless, particularly in regards to claims I see about security that are irrelevant unless you have the understanding that comes from operating and running your own servers. This includes running DDOS protection, so no cloudflare. 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. -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed•org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-20 1:26 ` Troy Benjegerdes @ 2014-08-20 1:34 ` Gregory Maxwell 2014-08-20 6:24 ` Wladimir 1 sibling, 0 replies; 25+ messages in thread From: Gregory Maxwell @ 2014-08-20 1:34 UTC (permalink / raw) To: Troy Benjegerdes; +Cc: Bitcoin Dev On Tue, Aug 19, 2014 at 6:26 PM, Troy Benjegerdes <hozer@hozed•org> wrote: > If a project cannot be organized enough to run its own hosting/web presense/ > counterintelligence/security that starts with installing an OS and patching > kernels, then it is really not wise for me to trust my financial future to > software written by such a group. Please take the hyperbole elsewhere. Good dialog it's going to happen with the insults and adhomenem. Regardless of where the repositories live their integrity is protected by digital signatures and cryptographic hashes. Running them elsewhere can be virtuous for other reasons, but it doesn't play much into this since the same tools must be used to guarantee their security. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-20 1:26 ` Troy Benjegerdes 2014-08-20 1:34 ` Gregory Maxwell @ 2014-08-20 6:24 ` Wladimir 2014-08-20 14:16 ` Mike Hearn 2014-08-23 5:53 ` Troy Benjegerdes 1 sibling, 2 replies; 25+ messages in thread From: Wladimir @ 2014-08-20 6:24 UTC (permalink / raw) To: Troy Benjegerdes; +Cc: Bitcoin Dev On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes <hozer@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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-20 6:24 ` Wladimir @ 2014-08-20 14:16 ` Mike Hearn 2014-08-23 5:59 ` Troy Benjegerdes 2014-08-23 5:53 ` Troy Benjegerdes 1 sibling, 1 reply; 25+ messages in thread From: Mike Hearn @ 2014-08-20 14:16 UTC (permalink / raw) To: Wladimir; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 606 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 753 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-20 14:16 ` Mike Hearn @ 2014-08-23 5:59 ` Troy Benjegerdes 0 siblings, 0 replies; 25+ messages in thread From: Troy Benjegerdes @ 2014-08-23 5:59 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev 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' hozer@hozed•org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-20 6:24 ` Wladimir 2014-08-20 14:16 ` Mike Hearn @ 2014-08-23 5:53 ` Troy Benjegerdes 1 sibling, 0 replies; 25+ messages in thread From: Troy Benjegerdes @ 2014-08-23 5:53 UTC (permalink / raw) To: Wladimir; +Cc: Bitcoin Dev On Wed, Aug 20, 2014 at 08:24:33AM +0200, Wladimir wrote: > On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes <hozer@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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-19 14:58 ` Wladimir 2014-08-20 1:26 ` Troy Benjegerdes @ 2014-08-30 3:33 ` Odinn Cyberguerrilla 1 sibling, 0 replies; 25+ messages in thread From: Odinn Cyberguerrilla @ 2014-08-30 3:33 UTC (permalink / raw) To: Wladimir; +Cc: Bitcoin Dev > On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik <jgarzik@bitpay•com> 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. > > Despite my complaining about github, I don't like the idea of moving > somewhere else. The current way of working - to use github for storing > the tree, and use a custom script for signing+merging - is fine with > me. > > Github has a low barrier to contribution. Almost every open source > developer already has a github account. Switching to something > self-hosted makes it more difficult for people to contribute. > > Plus if we have to take the hosting upon ourselves, we have to handle > sysadmin work ourselves as well. That's not a good use of the limited > manpower available. > > Also it will be a lot of work to migrate over all the current issues > and pulls. I don't look forward to that. I don't see the point of > this, sorry. > > Wladimir > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > I agree with Wladimir, keep it simple. There being many other more urgent questions to address, imho. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-19 12:02 [Bitcoin-development] Reconsidering github Jeff Garzik 2014-08-19 12:28 ` Dāvis Mosāns 2014-08-19 14:58 ` Wladimir @ 2014-08-19 15:44 ` Bryan Bishop 2014-08-19 17:04 ` Angel Leon 2014-08-19 18:54 ` Gregory Maxwell 2014-08-22 19:20 ` xor 4 siblings, 1 reply; 25+ messages in thread From: Bryan Bishop @ 2014-08-19 15:44 UTC (permalink / raw) To: Jeff Garzik, Bryan Bishop; +Cc: Bitcoin Dev On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik <jgarzik@bitpay•com> wrote: > As a first step, one possibility is putting the primary repo on > bitcoin.org somewhere, and simply mirroring that to github for each > push. Smaller first step would be to mirror the git repository on bitcoin.org, which is necessary anyway before switching primaries. - Bryan http://heybryan.org/ 1 512 203 0507 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-19 15:44 ` Bryan Bishop @ 2014-08-19 17:04 ` Angel Leon 0 siblings, 0 replies; 25+ messages in thread From: Angel Leon @ 2014-08-19 17:04 UTC (permalink / raw) To: Bryan Bishop; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 802 bytes --] -1 http://twitter.com/gubatron On Tue, Aug 19, 2014 at 11:44 AM, Bryan Bishop <kanzure@gmail•com> wrote: > On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik <jgarzik@bitpay•com> wrote: > > As a first step, one possibility is putting the primary repo on > > bitcoin.org somewhere, and simply mirroring that to github for each > > push. > > Smaller first step would be to mirror the git repository on > bitcoin.org, which is necessary anyway before switching primaries. > > - Bryan > http://heybryan.org/ > 1 512 203 0507 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 1730 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-19 12:02 [Bitcoin-development] Reconsidering github Jeff Garzik ` (2 preceding siblings ...) 2014-08-19 15:44 ` Bryan Bishop @ 2014-08-19 18:54 ` Gregory Maxwell 2014-08-22 19:20 ` xor 4 siblings, 0 replies; 25+ messages in thread From: Gregory Maxwell @ 2014-08-19 18:54 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev On Tue, Aug 19, 2014 at 5:02 AM, Jeff Garzik <jgarzik@bitpay•com> 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. > > To that end, I note that Linux does its own git repo, and now requires > 2FA: http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication > > As a first step, one possibility is putting the primary repo on > bitcoin.org somewhere, and simply mirroring that to github for each > push. The obvious thing to do is setup the second repository and get it going. Git doesn't really care all that much whats "primary". If we have a working workflow elsewhere then making a change won't be a leap of faith. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-19 12:02 [Bitcoin-development] Reconsidering github Jeff Garzik ` (3 preceding siblings ...) 2014-08-19 18:54 ` Gregory Maxwell @ 2014-08-22 19:20 ` xor 2014-08-22 19:31 ` Angel Leon 2014-08-23 6:17 ` Troy Benjegerdes 4 siblings, 2 replies; 25+ messages in thread From: xor @ 2014-08-22 19:20 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2801 bytes --] 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 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-22 19:20 ` xor @ 2014-08-22 19:31 ` Angel Leon 2014-08-23 6:17 ` Troy Benjegerdes 1 sibling, 0 replies; 25+ messages in thread From: Angel Leon @ 2014-08-22 19:31 UTC (permalink / raw) To: xor; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4243 bytes --] +1000. Don't fix it if it ain't broken. Don't kill community support. I for instance wouldn't have contributed or forked if the project hadn't been on github. "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" http://twitter.com/gubatron On Fri, Aug 22, 2014 at 3:20 PM, xor <xor@freenetproject•org> 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 > > > > > ------------------------------------------------------------------------------ > 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 > > [-- Attachment #2: Type: text/html, Size: 6680 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-22 19:20 ` xor 2014-08-22 19:31 ` Angel Leon @ 2014-08-23 6:17 ` Troy Benjegerdes 2014-08-23 11:38 ` Pieter Wuille ` (2 more replies) 1 sibling, 3 replies; 25+ messages in thread From: Troy Benjegerdes @ 2014-08-23 6:17 UTC (permalink / raw) To: xor; +Cc: bitcoin-development 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' hozer@hozed•org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-23 6:17 ` Troy Benjegerdes @ 2014-08-23 11:38 ` Pieter Wuille 2014-08-23 12:05 ` Drak 2014-08-23 15:56 ` Wladimir 2014-08-23 11:59 ` Angel Leon 2014-08-23 14:32 ` Peter Todd 2 siblings, 2 replies; 25+ messages in thread From: Pieter Wuille @ 2014-08-23 11:38 UTC (permalink / raw) To: Troy Benjegerdes; +Cc: Bitcoin Dev On Sat, Aug 23, 2014 at 8:17 AM, Troy Benjegerdes <hozer@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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-23 11:38 ` Pieter Wuille @ 2014-08-23 12:05 ` Drak 2014-08-23 15:56 ` Wladimir 1 sibling, 0 replies; 25+ messages in thread From: Drak @ 2014-08-23 12:05 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1404 bytes --] On 23 August 2014 12:38, Pieter Wuille <pieter.wuille@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. [-- Attachment #2: Type: text/html, Size: 1890 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-23 11:38 ` Pieter Wuille 2014-08-23 12:05 ` Drak @ 2014-08-23 15:56 ` Wladimir 1 sibling, 0 replies; 25+ messages in thread From: Wladimir @ 2014-08-23 15:56 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev >On Sat, Aug 23, 2014 at 1:38 PM, Pieter Wuille <pieter.wuille@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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-23 6:17 ` Troy Benjegerdes 2014-08-23 11:38 ` Pieter Wuille @ 2014-08-23 11:59 ` Angel Leon 2014-08-23 14:32 ` Peter Todd 2 siblings, 0 replies; 25+ messages in thread From: Angel Leon @ 2014-08-23 11:59 UTC (permalink / raw) To: Troy Benjegerdes; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5175 bytes --] I think this is the only project where people are concerened wether commit messages are signed or not. Commit messages should be merged only upon their correctness, not their signature. I could care less if I receive a buggy patch that's signed. http://twitter.com/gubatron On Sat, Aug 23, 2014 at 2:17 AM, Troy Benjegerdes <hozer@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: > > > > 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' > hozer@hozed•org > 7 elements earth::water::air::fire::mind::spirit::soul > grid.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 > [-- Attachment #2: Type: text/html, Size: 6649 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-23 6:17 ` Troy Benjegerdes 2014-08-23 11:38 ` Pieter Wuille 2014-08-23 11:59 ` Angel Leon @ 2014-08-23 14:32 ` Peter Todd 2014-08-23 17:44 ` Troy Benjegerdes 2 siblings, 1 reply; 25+ messages in thread From: Peter Todd @ 2014-08-23 14:32 UTC (permalink / raw) To: Troy Benjegerdes; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2489 bytes --] 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. > 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 -- 'peter'[:-1]@petertodd.org 0000000000000000284b07a00c97e4770dda4dee8b45994440226435ee05ab66 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-23 14:32 ` Peter Todd @ 2014-08-23 17:44 ` Troy Benjegerdes 2014-08-23 20:36 ` Paul Rabahy 2014-08-23 22:45 ` Peter Todd 0 siblings, 2 replies; 25+ messages in thread From: Troy Benjegerdes @ 2014-08-23 17:44 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-development 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' hozer@hozed•org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-23 17:44 ` Troy Benjegerdes @ 2014-08-23 20:36 ` Paul Rabahy 2014-08-23 20:54 ` Gregory Maxwell 2014-08-23 22:45 ` Peter Todd 1 sibling, 1 reply; 25+ messages in thread From: Paul Rabahy @ 2014-08-23 20:36 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 759 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 814 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-23 20:36 ` Paul Rabahy @ 2014-08-23 20:54 ` Gregory Maxwell 0 siblings, 0 replies; 25+ messages in thread From: Gregory Maxwell @ 2014-08-23 20:54 UTC (permalink / raw) To: Paul Rabahy; +Cc: Bitcoin Dev On Sat, Aug 23, 2014 at 1:36 PM, Paul Rabahy <prabahy@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). ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Bitcoin-development] Reconsidering github 2014-08-23 17:44 ` Troy Benjegerdes 2014-08-23 20:36 ` Paul Rabahy @ 2014-08-23 22:45 ` Peter Todd 1 sibling, 0 replies; 25+ messages in thread From: Peter Todd @ 2014-08-23 22:45 UTC (permalink / raw) To: Troy Benjegerdes; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2322 bytes --] 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 000000000000000006fb87cb8ec6e0981b134953f1916c513f7210b534a94b8b [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2014-08-30 3:34 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-19 12:02 [Bitcoin-development] Reconsidering github Jeff Garzik 2014-08-19 12:28 ` Dāvis Mosāns 2014-08-19 14:58 ` Wladimir 2014-08-20 1:26 ` Troy Benjegerdes 2014-08-20 1:34 ` Gregory Maxwell 2014-08-20 6:24 ` Wladimir 2014-08-20 14:16 ` Mike Hearn 2014-08-23 5:59 ` Troy Benjegerdes 2014-08-23 5:53 ` Troy Benjegerdes 2014-08-30 3:33 ` Odinn Cyberguerrilla 2014-08-19 15:44 ` Bryan Bishop 2014-08-19 17:04 ` Angel Leon 2014-08-19 18:54 ` Gregory Maxwell 2014-08-22 19:20 ` xor 2014-08-22 19:31 ` Angel Leon 2014-08-23 6:17 ` Troy Benjegerdes 2014-08-23 11:38 ` Pieter Wuille 2014-08-23 12:05 ` Drak 2014-08-23 15:56 ` Wladimir 2014-08-23 11:59 ` Angel Leon 2014-08-23 14:32 ` Peter Todd 2014-08-23 17:44 ` Troy Benjegerdes 2014-08-23 20:36 ` Paul Rabahy 2014-08-23 20:54 ` Gregory Maxwell 2014-08-23 22:45 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox