Is a bitcoin address collision possible if generating 90 million addresses every 4 hours?
I am running a test to see if I can obtain a successful bitcoin address collision after generating billions of addresses. I am not entirely sure how I would check them yet. Basically I have an extra 10TB hard drive and am running supervanitygen on my 32-core, 128gb ram linux work computer. It seems to be generating about 90,000,000 (90 million) addresses (address + private key pair) every 4 hours.
Do you think it's possible or likely to run into an address collision this way? Or perhaps if everyone in the world did the same thing? Or what if I waited 10-20 years, and then checked the addresses?
This is all just a test to see if the bitcoin system is secure enough for big investment decision.
bitcoin-core address-generation cryptography vanitygen
New contributor
add a comment |
I am running a test to see if I can obtain a successful bitcoin address collision after generating billions of addresses. I am not entirely sure how I would check them yet. Basically I have an extra 10TB hard drive and am running supervanitygen on my 32-core, 128gb ram linux work computer. It seems to be generating about 90,000,000 (90 million) addresses (address + private key pair) every 4 hours.
Do you think it's possible or likely to run into an address collision this way? Or perhaps if everyone in the world did the same thing? Or what if I waited 10-20 years, and then checked the addresses?
This is all just a test to see if the bitcoin system is secure enough for big investment decision.
bitcoin-core address-generation cryptography vanitygen
New contributor
add a comment |
I am running a test to see if I can obtain a successful bitcoin address collision after generating billions of addresses. I am not entirely sure how I would check them yet. Basically I have an extra 10TB hard drive and am running supervanitygen on my 32-core, 128gb ram linux work computer. It seems to be generating about 90,000,000 (90 million) addresses (address + private key pair) every 4 hours.
Do you think it's possible or likely to run into an address collision this way? Or perhaps if everyone in the world did the same thing? Or what if I waited 10-20 years, and then checked the addresses?
This is all just a test to see if the bitcoin system is secure enough for big investment decision.
bitcoin-core address-generation cryptography vanitygen
New contributor
I am running a test to see if I can obtain a successful bitcoin address collision after generating billions of addresses. I am not entirely sure how I would check them yet. Basically I have an extra 10TB hard drive and am running supervanitygen on my 32-core, 128gb ram linux work computer. It seems to be generating about 90,000,000 (90 million) addresses (address + private key pair) every 4 hours.
Do you think it's possible or likely to run into an address collision this way? Or perhaps if everyone in the world did the same thing? Or what if I waited 10-20 years, and then checked the addresses?
This is all just a test to see if the bitcoin system is secure enough for big investment decision.
bitcoin-core address-generation cryptography vanitygen
bitcoin-core address-generation cryptography vanitygen
New contributor
New contributor
New contributor
asked 5 hours ago
Anonymous UserAnonymous User
61
61
New contributor
New contributor
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Because of the Birthday paradox, you only need 280 addresses (despite there existing 2160 different address combinations) before a collision becomes probable.
Thankfully, that is still an enormous number. At 90 million addresses per 4 hours, it will take about 445 times the age of the universe to reach that number.
It's also irrelevant. Even if anyone - or everyone - generates 90 million addresses per 4 hours, there aren't that many addresses receiving funds. Thus only actually used addresses matter.
3
Also, in that case the collision would almost certainly be between two addresses you yourself generated... which isn't usually very useful for an attacker.
– G. Maxwell
4 hours ago
I'm confused at how you arrived at 2^80 for the birthday paradox. That's the square root of 2^160. Is that the calculation for all such schemes where the birthday paradox applies? In the wikipedia page, 23 marks the 50% line (is that what you mean be probable?), but it is 4 more than square root 366, a full 1% of the total more.
– fredsbend
9 mins ago
@fredsbend, the actual formula for the birthday paradox is complicated, but as the numbers get bigger, taking the square root becomes an increasingly better approximation to it. When talking about cryptography, the numbers are so huge that the difference isn't worth worrying about.
– Mark
1 min ago
@fredsbend Technically, the square root of the number of possibilities gives you a 39.3% probability for collisions (1-exp(-1/2)), that's about where you see the probability go from negligable to negligably not. 1/2 sqrt(n) gives you 11.75%. 2 sqrt(n) gives you 86.5%. In cryptography the exact factor is usually ignored, and we just say that you need approximately sqrt(n) elements to see a probable collision.
– Pieter Wuille
1 min ago
add a comment |
A very relevant answer can be found here: Is Each Bitcoin Address Unique?
This is a question of the birthday attack on the hashes. Bitcoin addresses (assuming the "normal" style starting with a 1) encode 160 bit hashes, so the output space has a possible 2^160 hashes. Because its a hash function, we assume all outputs have equal probability of being output.
At the rate you gave in the OP, you would generate 1.971 * 10^11 addresses in 1 year. Using the approximate birthday formula n^2 / 2H
, the probability of a collision in 1 year is thus roughly on the order of 10^-26. That is, basically 0. In 20 years that probability becomes around the order of 10^-24. Still basically 0. If all 8 billion people in the world generated addresses at that rate for 20 years, in total 3.1536 * 10^22 addresses would be generated. Even then, the probability of a collision is only around 0.0003. And remember that a collision like this is completely different from a targeted attack to find the private key of a specific address. If there was a collision, chances are overwhelming that there would be no funds ever sent to the address anyway, making the attack useless.
"A collision can't be a collision if there were no funds ever sent to the address" in regards to the last sentence of your answer. Other than that, great answer! Thank you!
– Anonymous User
1 hour ago
@AnonymousUser You say you're able to generate 90 million addresses per 4 hours. MeshCollider is pointing out that that's actually irrelevant, as there aren't 90 million addresses being paid at that rate.
– Pieter Wuille
1 hour ago
Oh gotcha, you may want to be more clear in that. Thanks again.
– Anonymous User
1 hour ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "308"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Anonymous User is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f83818%2fis-a-bitcoin-address-collision-possible-if-generating-90-million-addresses-every%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Because of the Birthday paradox, you only need 280 addresses (despite there existing 2160 different address combinations) before a collision becomes probable.
Thankfully, that is still an enormous number. At 90 million addresses per 4 hours, it will take about 445 times the age of the universe to reach that number.
It's also irrelevant. Even if anyone - or everyone - generates 90 million addresses per 4 hours, there aren't that many addresses receiving funds. Thus only actually used addresses matter.
3
Also, in that case the collision would almost certainly be between two addresses you yourself generated... which isn't usually very useful for an attacker.
– G. Maxwell
4 hours ago
I'm confused at how you arrived at 2^80 for the birthday paradox. That's the square root of 2^160. Is that the calculation for all such schemes where the birthday paradox applies? In the wikipedia page, 23 marks the 50% line (is that what you mean be probable?), but it is 4 more than square root 366, a full 1% of the total more.
– fredsbend
9 mins ago
@fredsbend, the actual formula for the birthday paradox is complicated, but as the numbers get bigger, taking the square root becomes an increasingly better approximation to it. When talking about cryptography, the numbers are so huge that the difference isn't worth worrying about.
– Mark
1 min ago
@fredsbend Technically, the square root of the number of possibilities gives you a 39.3% probability for collisions (1-exp(-1/2)), that's about where you see the probability go from negligable to negligably not. 1/2 sqrt(n) gives you 11.75%. 2 sqrt(n) gives you 86.5%. In cryptography the exact factor is usually ignored, and we just say that you need approximately sqrt(n) elements to see a probable collision.
– Pieter Wuille
1 min ago
add a comment |
Because of the Birthday paradox, you only need 280 addresses (despite there existing 2160 different address combinations) before a collision becomes probable.
Thankfully, that is still an enormous number. At 90 million addresses per 4 hours, it will take about 445 times the age of the universe to reach that number.
It's also irrelevant. Even if anyone - or everyone - generates 90 million addresses per 4 hours, there aren't that many addresses receiving funds. Thus only actually used addresses matter.
3
Also, in that case the collision would almost certainly be between two addresses you yourself generated... which isn't usually very useful for an attacker.
– G. Maxwell
4 hours ago
I'm confused at how you arrived at 2^80 for the birthday paradox. That's the square root of 2^160. Is that the calculation for all such schemes where the birthday paradox applies? In the wikipedia page, 23 marks the 50% line (is that what you mean be probable?), but it is 4 more than square root 366, a full 1% of the total more.
– fredsbend
9 mins ago
@fredsbend, the actual formula for the birthday paradox is complicated, but as the numbers get bigger, taking the square root becomes an increasingly better approximation to it. When talking about cryptography, the numbers are so huge that the difference isn't worth worrying about.
– Mark
1 min ago
@fredsbend Technically, the square root of the number of possibilities gives you a 39.3% probability for collisions (1-exp(-1/2)), that's about where you see the probability go from negligable to negligably not. 1/2 sqrt(n) gives you 11.75%. 2 sqrt(n) gives you 86.5%. In cryptography the exact factor is usually ignored, and we just say that you need approximately sqrt(n) elements to see a probable collision.
– Pieter Wuille
1 min ago
add a comment |
Because of the Birthday paradox, you only need 280 addresses (despite there existing 2160 different address combinations) before a collision becomes probable.
Thankfully, that is still an enormous number. At 90 million addresses per 4 hours, it will take about 445 times the age of the universe to reach that number.
It's also irrelevant. Even if anyone - or everyone - generates 90 million addresses per 4 hours, there aren't that many addresses receiving funds. Thus only actually used addresses matter.
Because of the Birthday paradox, you only need 280 addresses (despite there existing 2160 different address combinations) before a collision becomes probable.
Thankfully, that is still an enormous number. At 90 million addresses per 4 hours, it will take about 445 times the age of the universe to reach that number.
It's also irrelevant. Even if anyone - or everyone - generates 90 million addresses per 4 hours, there aren't that many addresses receiving funds. Thus only actually used addresses matter.
edited 1 hour ago
answered 4 hours ago
Pieter WuillePieter Wuille
45.8k394154
45.8k394154
3
Also, in that case the collision would almost certainly be between two addresses you yourself generated... which isn't usually very useful for an attacker.
– G. Maxwell
4 hours ago
I'm confused at how you arrived at 2^80 for the birthday paradox. That's the square root of 2^160. Is that the calculation for all such schemes where the birthday paradox applies? In the wikipedia page, 23 marks the 50% line (is that what you mean be probable?), but it is 4 more than square root 366, a full 1% of the total more.
– fredsbend
9 mins ago
@fredsbend, the actual formula for the birthday paradox is complicated, but as the numbers get bigger, taking the square root becomes an increasingly better approximation to it. When talking about cryptography, the numbers are so huge that the difference isn't worth worrying about.
– Mark
1 min ago
@fredsbend Technically, the square root of the number of possibilities gives you a 39.3% probability for collisions (1-exp(-1/2)), that's about where you see the probability go from negligable to negligably not. 1/2 sqrt(n) gives you 11.75%. 2 sqrt(n) gives you 86.5%. In cryptography the exact factor is usually ignored, and we just say that you need approximately sqrt(n) elements to see a probable collision.
– Pieter Wuille
1 min ago
add a comment |
3
Also, in that case the collision would almost certainly be between two addresses you yourself generated... which isn't usually very useful for an attacker.
– G. Maxwell
4 hours ago
I'm confused at how you arrived at 2^80 for the birthday paradox. That's the square root of 2^160. Is that the calculation for all such schemes where the birthday paradox applies? In the wikipedia page, 23 marks the 50% line (is that what you mean be probable?), but it is 4 more than square root 366, a full 1% of the total more.
– fredsbend
9 mins ago
@fredsbend, the actual formula for the birthday paradox is complicated, but as the numbers get bigger, taking the square root becomes an increasingly better approximation to it. When talking about cryptography, the numbers are so huge that the difference isn't worth worrying about.
– Mark
1 min ago
@fredsbend Technically, the square root of the number of possibilities gives you a 39.3% probability for collisions (1-exp(-1/2)), that's about where you see the probability go from negligable to negligably not. 1/2 sqrt(n) gives you 11.75%. 2 sqrt(n) gives you 86.5%. In cryptography the exact factor is usually ignored, and we just say that you need approximately sqrt(n) elements to see a probable collision.
– Pieter Wuille
1 min ago
3
3
Also, in that case the collision would almost certainly be between two addresses you yourself generated... which isn't usually very useful for an attacker.
– G. Maxwell
4 hours ago
Also, in that case the collision would almost certainly be between two addresses you yourself generated... which isn't usually very useful for an attacker.
– G. Maxwell
4 hours ago
I'm confused at how you arrived at 2^80 for the birthday paradox. That's the square root of 2^160. Is that the calculation for all such schemes where the birthday paradox applies? In the wikipedia page, 23 marks the 50% line (is that what you mean be probable?), but it is 4 more than square root 366, a full 1% of the total more.
– fredsbend
9 mins ago
I'm confused at how you arrived at 2^80 for the birthday paradox. That's the square root of 2^160. Is that the calculation for all such schemes where the birthday paradox applies? In the wikipedia page, 23 marks the 50% line (is that what you mean be probable?), but it is 4 more than square root 366, a full 1% of the total more.
– fredsbend
9 mins ago
@fredsbend, the actual formula for the birthday paradox is complicated, but as the numbers get bigger, taking the square root becomes an increasingly better approximation to it. When talking about cryptography, the numbers are so huge that the difference isn't worth worrying about.
– Mark
1 min ago
@fredsbend, the actual formula for the birthday paradox is complicated, but as the numbers get bigger, taking the square root becomes an increasingly better approximation to it. When talking about cryptography, the numbers are so huge that the difference isn't worth worrying about.
– Mark
1 min ago
@fredsbend Technically, the square root of the number of possibilities gives you a 39.3% probability for collisions (1-exp(-1/2)), that's about where you see the probability go from negligable to negligably not. 1/2 sqrt(n) gives you 11.75%. 2 sqrt(n) gives you 86.5%. In cryptography the exact factor is usually ignored, and we just say that you need approximately sqrt(n) elements to see a probable collision.
– Pieter Wuille
1 min ago
@fredsbend Technically, the square root of the number of possibilities gives you a 39.3% probability for collisions (1-exp(-1/2)), that's about where you see the probability go from negligable to negligably not. 1/2 sqrt(n) gives you 11.75%. 2 sqrt(n) gives you 86.5%. In cryptography the exact factor is usually ignored, and we just say that you need approximately sqrt(n) elements to see a probable collision.
– Pieter Wuille
1 min ago
add a comment |
A very relevant answer can be found here: Is Each Bitcoin Address Unique?
This is a question of the birthday attack on the hashes. Bitcoin addresses (assuming the "normal" style starting with a 1) encode 160 bit hashes, so the output space has a possible 2^160 hashes. Because its a hash function, we assume all outputs have equal probability of being output.
At the rate you gave in the OP, you would generate 1.971 * 10^11 addresses in 1 year. Using the approximate birthday formula n^2 / 2H
, the probability of a collision in 1 year is thus roughly on the order of 10^-26. That is, basically 0. In 20 years that probability becomes around the order of 10^-24. Still basically 0. If all 8 billion people in the world generated addresses at that rate for 20 years, in total 3.1536 * 10^22 addresses would be generated. Even then, the probability of a collision is only around 0.0003. And remember that a collision like this is completely different from a targeted attack to find the private key of a specific address. If there was a collision, chances are overwhelming that there would be no funds ever sent to the address anyway, making the attack useless.
"A collision can't be a collision if there were no funds ever sent to the address" in regards to the last sentence of your answer. Other than that, great answer! Thank you!
– Anonymous User
1 hour ago
@AnonymousUser You say you're able to generate 90 million addresses per 4 hours. MeshCollider is pointing out that that's actually irrelevant, as there aren't 90 million addresses being paid at that rate.
– Pieter Wuille
1 hour ago
Oh gotcha, you may want to be more clear in that. Thanks again.
– Anonymous User
1 hour ago
add a comment |
A very relevant answer can be found here: Is Each Bitcoin Address Unique?
This is a question of the birthday attack on the hashes. Bitcoin addresses (assuming the "normal" style starting with a 1) encode 160 bit hashes, so the output space has a possible 2^160 hashes. Because its a hash function, we assume all outputs have equal probability of being output.
At the rate you gave in the OP, you would generate 1.971 * 10^11 addresses in 1 year. Using the approximate birthday formula n^2 / 2H
, the probability of a collision in 1 year is thus roughly on the order of 10^-26. That is, basically 0. In 20 years that probability becomes around the order of 10^-24. Still basically 0. If all 8 billion people in the world generated addresses at that rate for 20 years, in total 3.1536 * 10^22 addresses would be generated. Even then, the probability of a collision is only around 0.0003. And remember that a collision like this is completely different from a targeted attack to find the private key of a specific address. If there was a collision, chances are overwhelming that there would be no funds ever sent to the address anyway, making the attack useless.
"A collision can't be a collision if there were no funds ever sent to the address" in regards to the last sentence of your answer. Other than that, great answer! Thank you!
– Anonymous User
1 hour ago
@AnonymousUser You say you're able to generate 90 million addresses per 4 hours. MeshCollider is pointing out that that's actually irrelevant, as there aren't 90 million addresses being paid at that rate.
– Pieter Wuille
1 hour ago
Oh gotcha, you may want to be more clear in that. Thanks again.
– Anonymous User
1 hour ago
add a comment |
A very relevant answer can be found here: Is Each Bitcoin Address Unique?
This is a question of the birthday attack on the hashes. Bitcoin addresses (assuming the "normal" style starting with a 1) encode 160 bit hashes, so the output space has a possible 2^160 hashes. Because its a hash function, we assume all outputs have equal probability of being output.
At the rate you gave in the OP, you would generate 1.971 * 10^11 addresses in 1 year. Using the approximate birthday formula n^2 / 2H
, the probability of a collision in 1 year is thus roughly on the order of 10^-26. That is, basically 0. In 20 years that probability becomes around the order of 10^-24. Still basically 0. If all 8 billion people in the world generated addresses at that rate for 20 years, in total 3.1536 * 10^22 addresses would be generated. Even then, the probability of a collision is only around 0.0003. And remember that a collision like this is completely different from a targeted attack to find the private key of a specific address. If there was a collision, chances are overwhelming that there would be no funds ever sent to the address anyway, making the attack useless.
A very relevant answer can be found here: Is Each Bitcoin Address Unique?
This is a question of the birthday attack on the hashes. Bitcoin addresses (assuming the "normal" style starting with a 1) encode 160 bit hashes, so the output space has a possible 2^160 hashes. Because its a hash function, we assume all outputs have equal probability of being output.
At the rate you gave in the OP, you would generate 1.971 * 10^11 addresses in 1 year. Using the approximate birthday formula n^2 / 2H
, the probability of a collision in 1 year is thus roughly on the order of 10^-26. That is, basically 0. In 20 years that probability becomes around the order of 10^-24. Still basically 0. If all 8 billion people in the world generated addresses at that rate for 20 years, in total 3.1536 * 10^22 addresses would be generated. Even then, the probability of a collision is only around 0.0003. And remember that a collision like this is completely different from a targeted attack to find the private key of a specific address. If there was a collision, chances are overwhelming that there would be no funds ever sent to the address anyway, making the attack useless.
answered 4 hours ago
MeshCollider♦MeshCollider
8,24131239
8,24131239
"A collision can't be a collision if there were no funds ever sent to the address" in regards to the last sentence of your answer. Other than that, great answer! Thank you!
– Anonymous User
1 hour ago
@AnonymousUser You say you're able to generate 90 million addresses per 4 hours. MeshCollider is pointing out that that's actually irrelevant, as there aren't 90 million addresses being paid at that rate.
– Pieter Wuille
1 hour ago
Oh gotcha, you may want to be more clear in that. Thanks again.
– Anonymous User
1 hour ago
add a comment |
"A collision can't be a collision if there were no funds ever sent to the address" in regards to the last sentence of your answer. Other than that, great answer! Thank you!
– Anonymous User
1 hour ago
@AnonymousUser You say you're able to generate 90 million addresses per 4 hours. MeshCollider is pointing out that that's actually irrelevant, as there aren't 90 million addresses being paid at that rate.
– Pieter Wuille
1 hour ago
Oh gotcha, you may want to be more clear in that. Thanks again.
– Anonymous User
1 hour ago
"A collision can't be a collision if there were no funds ever sent to the address" in regards to the last sentence of your answer. Other than that, great answer! Thank you!
– Anonymous User
1 hour ago
"A collision can't be a collision if there were no funds ever sent to the address" in regards to the last sentence of your answer. Other than that, great answer! Thank you!
– Anonymous User
1 hour ago
@AnonymousUser You say you're able to generate 90 million addresses per 4 hours. MeshCollider is pointing out that that's actually irrelevant, as there aren't 90 million addresses being paid at that rate.
– Pieter Wuille
1 hour ago
@AnonymousUser You say you're able to generate 90 million addresses per 4 hours. MeshCollider is pointing out that that's actually irrelevant, as there aren't 90 million addresses being paid at that rate.
– Pieter Wuille
1 hour ago
Oh gotcha, you may want to be more clear in that. Thanks again.
– Anonymous User
1 hour ago
Oh gotcha, you may want to be more clear in that. Thanks again.
– Anonymous User
1 hour ago
add a comment |
Anonymous User is a new contributor. Be nice, and check out our Code of Conduct.
Anonymous User is a new contributor. Be nice, and check out our Code of Conduct.
Anonymous User is a new contributor. Be nice, and check out our Code of Conduct.
Anonymous User is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Bitcoin Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f83818%2fis-a-bitcoin-address-collision-possible-if-generating-90-million-addresses-every%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown