Show Posts
|
Pages: [1]
|
I think update codebase and change the difficulty algo will solve the problem, no need to switch to pow/pos
|
|
|
Merged Mining with a reliable coin with decent hash rate ought to put a stop to these fork shenanigans.
ALSO, Fedoracoin(TIPS) are you going to answer my question? Could you clarify what you meant when you posted on June 5, 2016 by; "roll back to whatever before the fork"?
I actually just mean that if you are on the fork chain, your unconfirmed coin will never be able to get back. and it will eventually goes back to the sender's wallet once you recover your wallet. Then it will roll back to the transaction before the fork.
|
|
|
Whats the total number of coins with the new fork?
I do not think there is a mean to calculate that, but all these coin will lost on the new fork and will roll back to whatever before the fork.
|
|
|
Hi, need a little help. I use FedoraCoin wallet v.1.1.0.0. I add a lot of nodes, and from yesturday my wallet has 6-7 connection to the network, but it's still synchronizes. The problem is that the wallet is showing that left 127 weeks to be synchronized and today is the third day doing that without any progress.
have you try nodes I posted previously?
|
|
|
Last time gou gave us somes addnode!
I'll try to pu them in conf file, but they does'nt work!
So if anybody have good nodes?
Thank's!
These should working though. Try these: 46.101.131.172 82.196.3.108 188.166.181.68 178.62.72.53 188.166.165.61
|
|
|
just hanging in there, things will be solved eventually. good things will coming soon.
|
|
|
51% is one issue, the other one some of user may not notice that when transaction is over 2B tips wallet may stuck and sometime it will generate an extremely high transaction fees, and this cannot traced from blockexplorer. (not sure there are others, but it's two years old wallet.) You have valid points here, but you realize that in both proposed methodes there is single entity deciding what gets a checkpoint which is somewhat against the spirit of a decentralized currency? How would be decided who will be running i.e. the checkpointing master and would you all trust this person to do the right thing (tm) ?
True and not true. it always has some centralized thing and this can goes back to original dev team, as well. I believe they hold these nodes at the beginning. Are there running implementations of coins that use bytestamp so we could look at how it is done in the code? If yes, am I right that these just ask the website of bytestamp for a checkpoint or do they have to run the datacoin core too for this? I think you are right, but I am not sure, I am just saying this maybe a good idea to apply later on, which may need some research. But thank you for contribute your opinions.
|
|
|
Sorry to disturb you!
But we are mining fedora coin.
And the wallet doesn't Sync!
Can you give us somes new addnodes?
But i'll try to use somes nodes you have written!
Thank's for helping us!
These should get you start. addnode=157.161.128.55 addnode=162.243.210.240 addnode=5.255.66.44 addnode=121.41.6.161 addnode=87.98.182.171 addnode=195.169.203.83 addnode=75.175.72.22 addnode=83.217.145.16 addnode=1.180.115.42 addnode=1.180.127.34 addnode=1.204.205.190 addnode=101.201.44.98 addnode=103.253.43.162 addnode=106.18.236.121 addnode=107.178.109.224 addnode=110.102.31.124 addnode=111.202.79.11 addnode=113.224.106.107 addnode=113.225.190.58 addnode=113.238.194.55 addnode=115.195.98.0 addnode=115.249.113.161 addnode=115.28.42.60 addnode=116.114.20.99 addnode=118.212.34.186 addnode=118.240.102.196 addnode=119.32.198.152 addnode=120.27.198.28 addnode=121.41.6.161 addnode=121.56.176.123 addnode=122.234.17.150 addnode=122.88.21.127 addnode=122.94.239.244 addnode=123.184.164.230 addnode=123.191.87.22 addnode=124.163.209.205 addnode=124.92.78.105 addnode=124.92.87.177 addnode=128.199.148.87 addnode=139.196.230.81 addnode=139.214.116.243 addnode=146.199.169.254 addnode=148.251.19.213 addnode=151.16.156.41 addnode=162.243.210.240 addnode=162.255.117.105 addnode=163.158.195.2 addnode=167.160.36.126 addnode=169.237.118.11 addnode=172.77.155.251 addnode=172.93.110.218 addnode=174.78.200.194 addnode=175.149.155.55 addnode=175.15.206.2 addnode=175.168.97.109 addnode=178.140.25.85 addnode=182.200.142.136 addnode=182.200.247.232 addnode=182.200.39.61 addnode=183.167.195.116 addnode=183.69.222.67 addnode=183.69.223.146 addnode=188.226.194.191 addnode=192.99.13.67 addnode=192.99.241.164 addnode=192.99.62.23 addnode=192.99.8.126 addnode=209.188.18.52 addnode=212.65.7.40 addnode=218.95.60.50 addnode=221.181.214.226 addnode=222.161.208.11 addnode=223.100.0.116 addnode=223.101.73.82 addnode=223.158.205.124 addnode=223.255.20.148 addnode=223.73.119.211 addnode=24.125.85.28 addnode=27.189.200.150 addnode=27.189.204.154 addnode=36.78.46.24 addnode=39.169.114.4 addnode=46.254.11.158 addnode=46.55.194.23 addnode=49.70.187.149 addnode=5.135.108.204 addnode=50.142.213.254 addnode=50.72.139.239 addnode=59.54.120.60 addnode=61.166.207.37 addnode=68.101.63.60 addnode=69.85.95.101 addnode=71.177.147.44 addnode=71.222.61.146 addnode=72.186.22.189 addnode=73.66.169.235 addnode=74.207.243.85 addnode=78.209.19.92 addnode=78.63.158.220 addnode=78.70.226.125 addnode=79.131.12.15 addnode=80.145.155.185 addnode=80.145.158.170 addnode=80.98.68.110 addnode=82.196.15.75 addnode=84.107.174.140 addnode=84.241.146.26 addnode=85.214.125.73 addnode=85.239.131.22 addnode=85.25.44.119 addnode=86.198.52.77 addnode=88.15.242.11 addnode=88.206.187.1 addnode=88.75.157.62 addnode=90.32.33.219 addnode=90.79.92.58 addnode=91.153.109.149 addnode=94.167.83.54 addnode=95.222.28.243 addnode=96.252.143.147 addnode=96.41.46.191 addnode=98.115.147.74
|
|
|
Other question,Who can update?No dev,Dev disappeared since 2013
I was hoping current "dev" can handle this quickly, but it seems not the case for now. We may need someone with professional experience to do this, I am not sure how well the current 'dev' can handle this, and what they plan to do next, they seems not announce any plan since the fork happen. Let me take this chance to set straight what my position/role is here as I feel like being confused for "the dev" or "dev" : I like TIPS and it has been good to me at times in the past, that was reason enough for me to offer my support to bring TIPS on a new exchange (namely Alcurex and Cryptopia) when BTER was announcing to swap to SHA256 TIPS. That's what I do with every opensource project that is good to me, or teaches me something - I try to give something back within my possibilites. I live under the impression that's how the open source ecosystem is supposed to work. Since contributing people are a rather rare element on earth this was probably qualification enough to invite me to the dev-teams slack. I have offered there the little insight and knowledge I had and I refunded halibits loss from my pocket since a) he is a honest guy and doesn't deserve to make loss especially since he listed TIPS on Alcurex without any upfront payment and b) it was within my possibilities to keep halibit from delisting TIPS. That's all about it - I am not "dev" and certainly not "the dev", I do regard myself as a supporter or active community member - not more! I do not claim and have not claimed any more rights or weight than any other holder, miner or node maintainer in the TIPS community. I am absolutely sure that if you are willing to contribute, code, money, insight or just support the guys (teillagory, testbug and metamorphin) will be more than happy to welcome you on board. I actually hope my post inspires them to invite you to join and contribute your ideas and your code. It is a fact that you will need a professional coder for the plans you have, maybe that can be you? You sound like you have lot of experience or are maybe the experienced pro dev that is missing here. Elsewise this community probably will need to cough up some BTC for this professional dev you are looking for or convince one of the goodwilling pros to do it for the warm fuzzy feeling in the belly that you get when you do good things for free. I can't say if that person exists, but I wish sincerely good luck with finding him or her. I really hope you or somebody else will take the torch and become the much needed leader to bring TIPS to a new level and implement/code the changes you propose. I already thank you for that great effort and time you are willing to invest for the benefit of us all here. Thank you for clear explanation here. I am here because I am also a supporter, if nothing happened, I may just be quiet. But now, we really need to do some work, I am glad that testbug team actually did some good things such as the blockexplorer, but we should primary focus on update the wallet first. I do not want to claim how well I can do. But I definitely can provide support in someway. I PM testbug, but seems he/she is not interested to talk with me, but in case he/she changed his mind, he can still contact me. And since there is no "real" dev, we should all have the rights to vote what next we want to do, not one person decide everything. There are a lot more things we need to do, if we really want this coin grow.
|
|
|
Hello everyone,
I would like to bring everyone's attention here. We have suffered two large fork recently, and now it's really time to bring the topic here and would like get everyone's opinion. So we can move forward, because this can happened again.
Here are the opinions that we can work on.
1. Keep current algorithm, increase security, adding more nodes and checkpoints. 2. Use POW+POS 3. Merged mining 4. Update algorithm, like Scrypt-N, X15, etc.
Worst case hard fork may needed.
Please contribute your opinions. Or if you have better opinions, bring it. So we can make a better FedoraCoin together.
I apologize if this post manifests my complete ignorance, but feeling still being a n00b in cryptocurrencies I have a few question regarding the proposed measures above and I hope to receive answers that allow me to improve my knowledge: Re: 1.Checkpoints are fine, but they always reference a point in the past before or at best when the wallet/src was released. Given the fork doesn't go back further than the checkpoint it is my understanding that a checkpoint helps nothing to prevent a fork from happening (except speeding up synching from scratch), is this assumption completely off? Though TIPS needs newer checkpoints for the getchainvalue function to work halfway performant, I don't believe it helps protecting from forks like the ones we saw. I estimate the current TIPS network to something around 60-80 nodes. How many nodes more would you think would be needed and how do you think this can keep a fork like the one we experienced from happening? Re: 2.A POS/POW hybrid certainly serves as good protection against a 51% POW attack, however if you look at the richlist you will see that the top 2 wallets have >40% of the total supply. Assuming that never all supply will be staking and assuming those two wallets will stake, they can easily outgrow a majority of staking weight. I really have no clue if my suspicion here holds any ground, but I hope an experienced person with better skills can enlighten us. Re: 3.That seems to me like the best option to avoid a fork when enough pools join and merge mine TIPS. If I look at DOGE right now, it has ~900Gh - I guess that's much harder to attack than the current ~40Gh that TIPS has (or much less when it forked). However I am pretty sure it would move price of TIPS downwards when there is no more hard cost associated with mining TIPS. Re: 4.Could you explain how changing the mining algo would protect TIPS from an attack/fork? What exactly are you trying to achieve with an algo swap? You realize that you sound here like the takeover dev that also appeared out of nowhere suddenly and wanted to change the algo? May I ask if you are in any way affiliated with the SHA256 takeover-dev ? I agree though that the coin needs an update, my opinion from digging through code is that it will get problematic to use - to say the least - once # 1,664,000 is reached. I will highly appreciate if you can take the time to address my naive questions and help me toward a better understanding of how cryptocurrencies work. It’s okay if you do not agree with me, but I just need to solve these problems as soon as possible. It seems the dev team do not start doing anything related to this yet, so I just bring the topic, so everyone can discuss what the best opinion is. 1. You assumption is correct, but we need more than that. Need to fix vulnerabilities, we can add checkpoint periodically for those nodes. We can adopt new methods, two idea about checkpoints are very interesting and we can think about it. . Cross checkpoint: http://www.bytestamp.net/c/what advanced checkpointing: http://www.coindesk.com/feathercoin-secures-block-chain-advanced-check-pointing/Also we can try this Two Phase POW method. A paper can be found here: http://fmt.cs.utwente.nl/files/sprojects/268.pdf2. Read this paper, it will answer your concern and you can learn. http://eprint.iacr.org/2014/452.pdf3. True, agree. 4. I do agree this is the worst and bad idea, but technically it can, because the old massive fork may not have the same hashing power anymore. And for the recorded, I have no relation with the swap team you mention, I am only list what I can think of, people can discussion what they think. And yes, I jump from nowhere, and I think I do not need you a permission to talk here. You sounds like very aggressive, but it’s fine. If one day, president jump here and make a statement, you will say the same thing, that he jump from nowhere. If we want to keep a thing running longer, we need also adopting and learn new things and try to apply those good ones. My opinion is we can try 1 first (current best opinion), but do need do good research and technical improvement. Then, we can try 2. (POW+POS) if 1 is not doing well. 3. Maybe later? I am not sure. 4. Seems bad though, we can ignore it. And for the record, again, you do not need to agree with me. This is the primary issue, and need to be solve first (as soon as possible), for people who hold those coins, it will not worth a cent, if it's not on any exchanging platform. And for those platform perform well, they do need secure. So we can make this coin more popular, otherwise, if we do everything slow and wait and ignore, it will toward the death at the end. Other question,Who can update?No dev,Dev disappeared since 2013 I was hoping current "dev" can handle this quickly, but it seems not the case for now. We may need someone with professional experience to do this, I am not sure how well the current 'dev' can handle this, and what they plan to do next, they seems not announce any plan since the fork happen.
|
|
|
Hello everyone,
I would like to bring everyone's attention here. We have suffered two large fork recently, and now it's really time to bring the topic here and would like get everyone's opinion. So we can move forward, because this can happened again.
Here are the opinions that we can work on.
1. Keep current algorithm, increase security, adding more nodes and checkpoints. 2. Use POW+POS 3. Merged mining 4. Update algorithm, like Scrypt-N, X15, etc.
Worst case hard fork may needed.
Please contribute your opinions. Or if you have better opinions, bring it. So we can make a better FedoraCoin together.
I apologize if this post manifests my complete ignorance, but feeling still being a n00b in cryptocurrencies I have a few question regarding the proposed measures above and I hope to receive answers that allow me to improve my knowledge: Re: 1.Checkpoints are fine, but they always reference a point in the past before or at best when the wallet/src was released. Given the fork doesn't go back further than the checkpoint it is my understanding that a checkpoint helps nothing to prevent a fork from happening (except speeding up synching from scratch), is this assumption completely off? Though TIPS needs newer checkpoints for the getchainvalue function to work halfway performant, I don't believe it helps protecting from forks like the ones we saw. I estimate the current TIPS network to something around 60-80 nodes. How many nodes more would you think would be needed and how do you think this can keep a fork like the one we experienced from happening? Re: 2.A POS/POW hybrid certainly serves as good protection against a 51% POW attack, however if you look at the richlist you will see that the top 2 wallets have >40% of the total supply. Assuming that never all supply will be staking and assuming those two wallets will stake, they can easily outgrow a majority of staking weight. I really have no clue if my suspicion here holds any ground, but I hope an experienced person with better skills can enlighten us. Re: 3.That seems to me like the best option to avoid a fork when enough pools join and merge mine TIPS. If I look at DOGE right now, it has ~900Gh - I guess that's much harder to attack than the current ~40Gh that TIPS has (or much less when it forked). However I am pretty sure it would move price of TIPS downwards when there is no more hard cost associated with mining TIPS. Re: 4.Could you explain how changing the mining algo would protect TIPS from an attack/fork? What exactly are you trying to achieve with an algo swap? You realize that you sound here like the takeover dev that also appeared out of nowhere suddenly and wanted to change the algo? May I ask if you are in any way affiliated with the SHA256 takeover-dev ? I agree though that the coin needs an update, my opinion from digging through code is that it will get problematic to use - to say the least - once # 1,664,000 is reached. I will highly appreciate if you can take the time to address my naive questions and help me toward a better understanding of how cryptocurrencies work. It’s okay if you do not agree with me, but I just need to solve these problems as soon as possible. It seems the dev team do not start doing anything related to this yet, so I just bring the topic, so everyone can discuss what the best opinion is. 1. You assumption is correct, but we need more than that. Need to fix vulnerabilities, we can add checkpoint periodically for those nodes. We can adopt new methods, two idea about checkpoints are very interesting and we can think about it. . Cross checkpoint: http://www.bytestamp.net/c/what advanced checkpointing: http://www.coindesk.com/feathercoin-secures-block-chain-advanced-check-pointing/Also we can try this Two Phase POW method. A paper can be found here: http://fmt.cs.utwente.nl/files/sprojects/268.pdf2. Read this paper, it will answer your concern and you can learn. http://eprint.iacr.org/2014/452.pdf3. True, agree. 4. I do agree this is the worst and bad idea, but technically it can, because the old massive fork may not have the same hashing power anymore. And for the recorded, I have no relation with the swap team you mention, I am only list what I can think of, people can discussion what they think. And yes, I jump from nowhere, and I think I do not need you a permission to talk here. You sounds like very aggressive, but it’s fine. If one day, president jump here and make a statement, you will say the same thing, that he jump from nowhere. If we want to keep a thing running longer, we need also adopting and learn new things and try to apply those good ones. My opinion is we can try 1 first (current best opinion), but do need do good research and technical improvement. Then, we can try 2. (POW+POS) if 1 is not doing well. 3. Maybe later? I am not sure. 4. Seems bad though, we can ignore it. And for the record, again, you do not need to agree with me. This is the primary issue, and need to be solve first (as soon as possible), for people who hold those coins, it will not worth a cent, if it's not on any exchanging platform. And for those platform perform well, they do need secure. So we can make this coin more popular, otherwise, if we do everything slow and wait and ignore, it will toward the death at the end.
|
|
|
Hello everyone,
I would like to bring everyone's attention here. We have suffered two large fork recently, and now it's really time to bring the topic here and would like get everyone's opinion. So we can move forward, because this can happened again.
Here are the opinions that we can work on.
1. Keep current algorithm, increase security, adding more nodes and checkpoints. 2. Use POW+POS 3. Merged mining 4. Update algorithm, like Scrypt-N, X15, etc.
Worst case hard fork may needed.
Please contribute your opinions. Or if you have better opinions, bring it. So we can make a better FedoraCoin together.
|
|
|
Hello everyone,
I would like to bring everyone's attention here. We have suffered two large fork recently, and now it's really time to bring the topic here and would like get everyone's opinion. So we can move forward, because this can happened again.
Here are the opinions that we can work on.
1. Keep current algorithm, increase security, adding more nodes and checkpoints. 2. Use POW+POS 3. Merged mining 4. Update algorithm, like Scrypt-N, X15, etc.
Worst case hard fork may needed.
Please contribute your opinions. Or if you have better opinions, bring it. So we can make a better FedoraCoin together.
|
|
|
Hello everyone,
I would like to bring everyone's attention here. We have suffered two large fork recently, and now it's really time to bring the topic here and would like get everyone's opinion. So we can move forward, because this can happened again.
Here are the opinions that we can work on.
1. Keep current algorithm, increase security, adding more nodes and checkpoints. 2. Use POW+POS 3. Merged mining 4. Update algorithm, like Scrypt-N, X15, etc.
Worst case hard fork may needed.
Please contribute your opinions. Or if you have better opinions, bring it. So we can make a better FedoraCoin together.
|
|
|
|