can i aks my BTC donation back in the Hacker event?  busoni you are a honest guy, i like you. hope you can handle this tough thing correctly. thanks  You actually can, I don't hold people to that. It is pertinent that the coin was hard forked to change the maximum supply. We have not examined all the changes made, but this may strengthen the case for the MAX_MONEY issue being negligence rather than laying the foundation for a nefarious plan. Nevertheless, the variable could have been deliberately left unchanged for the same reasons, and in any case, it indicates sloppy coding that opens the coin up to, for example, a much larger double spend attack. We're going to look into this further, but an apology may be in order for not coming to dev privately first. There is also the issue of the anon implementation proposed, which even by the dev's admission is highly vulnerable to "cheating." I would never list a coin that relied on the honesty of people operating a mixing pool. It would be trivial for them to steal coins and impossible to prove that they had done so. I don't agree with you, these parameters are simply irrelevent. We did not miss them, we simply think there's no need. We welcome anyone to review our code, and we are happy to discuss with anyone. But blunders like this are not agreed. Your ignorance simply caused a lot unnecessary confusion. Should you contact us, we would have explained all to you. |
|
|
|
lmao, this is a complete joke, if this is done by poloniex tech staff, I feel really sorry to them Here is a reply from a forum member (timerland) to that accusation: Is this an amateur or a 10-years-old? The max coin limits the maximum coin, but does it mean the maximum coin will be generated?? Not at all. The generated coin depends on the formula in 3functions: - GetProofOfWorkReward() - GetProofOfStakeReward() and - GetProofOfWorkBonusRewardFactor() These functions define how many coins will be generated. Moreover, even the system generates more coins than the MAX_MONEY defined above, there will be no problem at all, go look at the code. If Poloniex tech staff is that dumb, I feel very sorry for them, it is a joke! This member stated the fact. These 3 functions determined how many coins will be generated. The MAX_MONEY is largely irrelavent. All it does (and the dAmount), is to check each transaction if this limit exceeded. I can't believe this, it's like a circus |
|
|
|
OK SUPER anon feature works fine for me! sending 123.456 SUPERs to my other wallet in another machine:  The system apparently split it into two parts, and sent to 2 different addresses (sometimes I see split into 3 parts):  And my other wallet receives it, in 123.456 SUPERs, no split. The transaction is fast   Great job devs!!Thanks. The best way to test is to set up two wallets and use anon to send from one to the other, you can see how it works, and you can use console (Help->Debug Window->Console) to check the transactions (use gettransaction <txid> command). See if you can find the true source of a tx you received, good luck  |
|
|
|
Some people asked for details of our plan and implementations, here are some information on it. I'll use question/answer format to give details. Please post more questions if you have, the dev team will do our best to answer them. Q: What is the overall plan for SUPER to support anonymous features?A: Our ultimate goal is to create a peer-to-peer and completely de-centralized anonymous system. This is shown in the following diagram. Any node can become an intermediate "mixing" node, if some minimum requirements are satisfied. There is no central control parts. Everything is peer-to-peer and de-centralized. Remember that this is a trustless system, any node may cheat if it can. In order to achieve this goal, we divide our work into 2 steps: - Phase-1. To achieve anonymous wallet with a simplified, and easy to implement system
- Phase-2. To implement a fully de-centralized peer-to-peer anonymous system
What is an anonymous system? Simply put, it is a system that people can not trace clearly the transactions from the blockchain, and see where the transaction really originated and where it is terminated. This protects people's privacy. So why we don't go directly to our end-goal? This is because from our surveys and investigations, it is very complex and difficult to achieve a completely decentralized anonymous system. The key here is the "trust". When you do A->X->B, where X is some sort of the middle "mixer" node, the send or sign or commit of A->X and X->B (or its equivalent, such as a double-signed address, mini-escrow, etc), can not completely happen simultaneously, the one side (sender or Mixer-node) that has the last act can always cheat, though sometimes the cheat does not give the cheater benefits, but it can cause damage to the other party. Therefore, a complete trustless system is more difficult to be implemented (though it is possible - we'll discuss some more below). For this reason, in phase-1 we decided to develop a system that will depend on some sort of the trust, it is much easier to implement, and will give people the anonymous feature. This trust will be done through the dev team, or a credible mining pool. Q: So what is your Phase-1 solution?A: Our initial anon solution will involve some middle trusted mixing pools. This is shown in the following diagram: The mixing pools will be hosted initially by dev team, and can also be hosted by credible mining pools. The anon send will be directed to these mixing pools by wallet and mixed and then send to its destination. Basically it is done like this: A (source) -> {Xi} (i = 1, ..., m), then {Yi} (i = 1, ..., n)->B (destination) where {Xi} and {Yi} are randomly chosen addresses from a large pool of addresses (belonging to a mixing pool, and these addresses are periodically refreshed, phased out, and created). The source amount from A is split randomly into m parts (for now we choose m = 2,3 or 4 randomly in the anon version we will release for testing, but it will be a configurable parameters later), they are sent to m random addresses in randomly chosen mixing pool. The pool, on confirming the amounts received, will send the same amount in n parts to the destination (for our testnet we choose n=1, again this can be changed and configured). The result transaction is not traceable (at least extremely difficult to trace, given the large number of addresses in the mixing pool and dynamism of the addresses). The main part of our phase-1 solution is implemented, and we will release a version for testnet shortly. Q: Sounds good, is mixing pool software and coin wallet client are two different software?A: Absolutely not. They are exactly the same. It is the SUPER coin wallet. Eventually this will be used for peer-to-peer system (in phase-2), so no reason to be different. Now we configure only a few special nodes as trusted nodes. Once we implement the trustless system in phase-2, no special config is needed. Q: What is a trust system, and what is a trustless system?A: A trust system will have at least one node that everyone trusts. This node will never cheat. Other nodes may or may not cheat. A trustless system is that any nodes will cheat if they can. So to implement a trustless system it is more difficult as you have to implement mechanisms to prevent or discourage a node to cheat. If a node cheats, it will lose much more than it gains. Q: Can you give some details on the mixing pool?A: OK, it is basically a wallet client, with a pool feature configured as shown below. A array of the incoming/outgoing addresses are created and refreshed dynamically, and randomly chosen for each transaction. Incoming and outgoing addresses balance their coins with predefined algorithms. Q: Looks good for Phase-1. What about Phase-2? Is it feasible?A: Phase-2 is absolutely feasible, albeit more difficult. We actually already defined a workable scheme, and work on details now. It involves a complex system with multi-signature (m-to-n signature) addresses and multi-signature transactions. We can not reveal more details now. We will publish the full scheme design details after we implement, test and release it. The Phase-2 will be built on top of the Phase-1 codebase. In phase-2, any node (wallet client) can become an intermediate mixing node if it satisfy some minimum requirements (e.g. minimum balance, network connectivity etc). |
|
|
|
 Supercoin Version 1.2Download: http://www.super-coin.net/SuperCoin12.zip Download2: https://mega.co.nz/#!EoJAURQZ!Mn-vb1gXBNbdAQzYsqUKIcjq8PXGRsRu15_-L0riQFo This is a mandatory upgrade, please upgrade your wallet as soon as possible. The switch point is PoW block 17500 (not overall (PoW+PoS) block). This will be reached in 3-4 days from now.Initial PoW Payout 512 coins per block will last about 6 more block-days. Then the payout will be halved to 256 coins. From this point on, the payout will be halved every 10 block-days. Superblocks will remain the same as before. Once the payout reaches 1-2 coins per block, the PoW blocks will be cutoff and no PoW will be allowed. After it, the coin will become a pure PoS coin. The reason we decided to change this, is mainly for security reasons. As the very low PoW payout will cause very low hash rate, and the network is vulnerable to be attacked. PoS payout and super-PoS blocks will remain unchanged. With updated payout scheme, the total PoW coins will be about 18.2 millions and total coins (PoW + PoS) is estimated at about 50 millions. |
|
|
|
Explained why we do it first in my early post. Though i share most of your concerns, we had nearly 20 days of mining. What is better for us really is a matter of science. But though we have tiny amount people in SUPER community, you were the cause we started work on anonymous feature, we were happy with current model otherwise. I think core members can take SUPER even further.
It is obvious multipools getting more and more piece from hashing and more dumpers coming over. Also dropping reward thing tested and it seems worked well for the other cryptos.
After reward drop we will be very rare crypto and uses own anonymous feature which i believe much simpler and fun to use than current others. Anonymous feature is something beyond Bitcoin. If this understood well we will have a better future.
I thank you for listening to the community & myself to improve the coin. I agree that high inflation affects the coin negatively. So yes, it will need to be changed. But you also know that SUPER hasn't actually been very popular until recently when you announced anonymous feature. It is the current "buzz" word that either make or break the coin these days. So it's great that you took that on-board. Many coins say they will release it or are in the works but actually do not have the wallet released. If you release it and if it works, then this will bring more of everything. (including more multipools) But this will increase awareness for this coin. That's very important. Well, I think.... 1. Work on the hard fork to reduce the number of coins and/or inflation. Announce what & when it'll change once finalized. 2. Continue to release the "test" anon wallet this weekend as you tweeted. (people will dump significantly if it gets delayed) It'll be a win win situation IMO. Yes we heard our community and we are preparing a new version adjusting the coin release scheme. Meanwhile, we will not delay the testing of our anon features. We will release an anon version for testnet the latest this coming weekend, so the community can test and give us feedback and improvement suggestions. We will also release more details of our anon implementation and plans. SUPER is a great coin, just look at its transaction speed, it is amazing! |
|
|
|
DEV we need quick Halves, other wise Multipool will keep dumping their coins until pow period ends...
you can also check dark thread, at first the reward is 500coin then reduce to 25 coins after they realised the Multipool dumping.
similar thing happened with XC coin. they ends their mining period soon after they realized Multipool keep dumping
Further more, POS mining is a more greener way for coin distribution, it do not need GPU cards and waste electricity!
what's the meaning of pow period?
Halves block reward to 64 coins, Please..
I understand your point and concerns, and we will seriously consider your proposal. We know this is what happened to XC and other coins. We will protect our community's best interests against multipools. The Supercoin dev team will make a decision on this matter. Thank you for your great support to us. |
|
|
|
Please First Halve the block reward to 256 coin this week..
Then Halve the block reward to 128coins next week..
Then Halve the block reward to 64coins and keep the block reward fixed @64 coin or 32coins Sorry we will not change the spec without any critical issues... |
|
|
|
Sending with anonymous feature will become very easy, just click "anonymous send" checkbox before clicking the "send" button. It is the same user interface. Of course, you can also choose to use normal send if you want. No additional command-line command to use:  By the way, we will try to release the wallet with anon features for tests this weekend. Remember, for now we only allow the anon features in testnet for testing purpose. It will be the same client, so you can switch back and forth between formal SuperCoin network and testnet (just change the testnet=1 or 0 in config file and restart the qt client). |
|
|
|
Dev, are you going to publish the anon feature source code? or hide them like what XC dev did? We will publish our code once everything is implemented and tested. We may put a delay there, due to many copy-and-paste coins. But eventually we will publish the code. |
|
|
|
RE: anon features, dev, do you use Fedoracoin or XC code base? Can you give some more details on the strategy you are using? I heard the complete de-centralized solution not working, can you please comment?
We don't use any Fedoracoin or XC code (XC code not available anyway). We developed our code from scratch. This said, in the future it is possble that we may use Fedoracoin's mixerann system (it is not currently used). As for a complete de-centralized solution, you are right, we are not aware an algorithm that works. The key thing is the "trust". It's like you go down the street, see a person, and ask him "can you please give $100 to Dave in that shop? And I will give you $100?". Though you may find a good person to do it, in general, you have no guarantee that this guy will not take the money and run away, or that he gave $100 to Dave, he has no guarantee you will give him $100. Thus in our initial phase implementation, some trust mixer nodes are required (dev team will provide such nodes initially). |
|
|
|
Let me show you an example in our testing: A user send 999.0123 coins from address A (mxcMnGPthZp7rzQ7TUg8kZcbVyB8CrXy8p) to address B (myKydMhECoFyY2iAWgwuEVbthej1sKHFdR) (1) Send from sender's Qt client  (2) The send is automatically split into 2 (random) parts and send to 2 different addresses X1 (mquFq9qNwDDVbNKLwThvhFDpbFPot8HixR) and X2 (mgniPoAcsSzvpfisxg1cyueUvqApAZbwbK). This is displayed in sender's tx list (2 red ones).  (3) On receiver's side, he sees the amount arrived (from yet another address Y (n1mFH2L7PhhMc6BLFMDoD7tDc2AXtZGJS4) - you don't see it in current tx, but if you check its in-tx, you will see it)  The 3 related tx details are posted below. It's basic impossible to detect the original source address of this transaction, from the receiving transaction. {
"txid" : "6c7a8d751381e088c3c7eb7db3ebf13f6c148456cb392f05b83fb86f626e804c",
"version" : 1,
"time" : 1402462734,
"locktime" : 0,
"vin" : [
{
"txid" : "0694419082ee689ec21681db4822f3453126fce079d77c2db6ab5bb34e568585",
"vout" : 0,
"scriptSig" : {
"asm" : "304402206407e11bf057b3f5cdd97c31729e2d7266528dbca39ee87cee0b8675f133362f022044971c0e34c380a3051b8e92f3df0b7c5caa19b02f54801ae38345eff241b2fd01 03c288f76512d3093439ecbd2c78c5cf997e41132d08ce44ae3a116e099bdf6faf",
"hex" : "47304402206407e11bf057b3f5cdd97c31729e2d7266528dbca39ee87cee0b8675f133362f022044971c0e34c380a3051b8e92f3df0b7c5caa19b02f54801ae38345eff241b2fd012103c288f76512d3093439ecbd2c78c5cf997e41132d08ce44ae3a116e099bdf6faf"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 52.45424200,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 c4737f339ef96dba8decbd799874aae3f9224a68 OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"myRh6WvjaN8riGEkrdMuFd5Vg8L7MyfpG8"
]
}
},
{
"value" : 459.54565800,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 71e90c272a86ec027071c7de1df5a14b8a187937 OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mquFq9qNwDDVbNKLwThvhFDpbFPot8HixR"
]
}
}
],
"amount" : -459.54565800,
"fee" : -0.00010000,
"confirmations" : 11,
"blockhash" : "000005fb04de17a44bcfc2195aed1878e890a1898799772a7fcf2e4dc80e1284",
"blockindex" : 2,
"blocktime" : 1402462748,
"txid" : "6c7a8d751381e088c3c7eb7db3ebf13f6c148456cb392f05b83fb86f626e804c",
"time" : 1402462734,
"timereceived" : 1402462734,
"details" : [
{
"account" : "",
"address" : "mquFq9qNwDDVbNKLwThvhFDpbFPot8HixR",
"category" : "send",
"amount" : -459.54565800,
"fee" : -0.00010000
}
]
}
{
"txid" : "7f14e6f0b00e98b25b4acf5463ca5419f6ec86673d5540dd8da3c8c147eb90c0",
"version" : 1,
"time" : 1402462734,
"locktime" : 0,
"vin" : [
{
"txid" : "ae2242db5b8002af78b5969c353a0d167267f9e24dac7535d90610a6cbf1a607",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100d5e024b40f00c8f08be5ba2ee55c14e67bd186e308d5612ef34b63bc13ea452302202dd4d883cebd384774c1f586c6a445c8be5615c90886a66f70184faf32be71d701 022221c6c6804456de70dfe332c9a8f1694b27c1ddf5023faf980324952de08c79",
"hex" : "483045022100d5e024b40f00c8f08be5ba2ee55c14e67bd186e308d5612ef34b63bc13ea452302202dd4d883cebd384774c1f586c6a445c8be5615c90886a66f70184faf32be71d70121022221c6c6804456de70dfe332c9a8f1694b27c1ddf5023faf980324952de08c79"
},
"sequence" : 4294967295
},
{
"txid" : "6300d320e006a7be95556f38d80c2225f73761dfc6998d5f1765e441d7972e59",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100e780ee7216f56a1075a068e3bf9a32778b246ca153abe6551ebf5db3a50b3181022012929c5a2be93e7167ac7eec028764da4be4bbe7c685b974a7a294fab99bfa3201 02db386f4f155744e11dee9b182cb014b89c3d7104827303bc4f8d55b822961ddd",
"hex" : "483045022100e780ee7216f56a1075a068e3bf9a32778b246ca153abe6551ebf5db3a50b3181022012929c5a2be93e7167ac7eec028764da4be4bbe7c685b974a7a294fab99bfa32012102db386f4f155744e11dee9b182cb014b89c3d7104827303bc4f8d55b822961ddd"
},
"sequence" : 4294967295
},
{
"txid" : "2d7cd6c42fe591bbcdd4c7fbc95c5b92c8c9f57406b48c2fd48c42d3f224a0a1",
"vout" : 0,
"scriptSig" : {
"asm" : "30440220704aee08f4ea413967a65f43d80618eebcba407f5ec47f9bb4dd861294feb670022028e8b81335381438387f4a6aca80d4000f97aadda149360dca12b9caa49387cb01 022221c6c6804456de70dfe332c9a8f1694b27c1ddf5023faf980324952de08c79",
"hex" : "4730440220704aee08f4ea413967a65f43d80618eebcba407f5ec47f9bb4dd861294feb670022028e8b81335381438387f4a6aca80d4000f97aadda149360dca12b9caa49387cb0121022221c6c6804456de70dfe332c9a8f1694b27c1ddf5023faf980324952de08c79"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.56089498,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 3845a744f2480b47443d20122171e80971194ec8 OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mkeVaQ7XR9gS2mTDKeH378r2agpuiCvqna"
]
}
},
{
"value" : 539.46664200,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 0df32d5dd2f602fac3ef26452c91fcb15d4c91af OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mgniPoAcsSzvpfisxg1cyueUvqApAZbwbK"
]
}
}
],
"amount" : -539.46664200,
"fee" : -0.00010000,
"confirmations" : 11,
"blockhash" : "000005fb04de17a44bcfc2195aed1878e890a1898799772a7fcf2e4dc80e1284",
"blockindex" : 3,
"blocktime" : 1402462748,
"txid" : "7f14e6f0b00e98b25b4acf5463ca5419f6ec86673d5540dd8da3c8c147eb90c0",
"time" : 1402462734,
"timereceived" : 1402462734,
"details" : [
{
"account" : "",
"address" : "mgniPoAcsSzvpfisxg1cyueUvqApAZbwbK",
"category" : "send",
"amount" : -539.46664200,
"fee" : -0.00010000
}
]
}
{
"txid" : "d0ce1a74c9e03fca3a507dfef2d0e7e8e6bc0b9b8180676a6fc481a275e0b670",
"version" : 1,
"time" : 1402462729,
"locktime" : 0,
"vin" : [
{
"txid" : "81fac0abe2b4ecc9002dbc79a6ac0dfd4ee6cbfdb8f491e98dbaf9be835eaa69",
"vout" : 1,
"scriptSig" : {
"asm" : "3045022100e932e4cb29d6b6fd76dd943d162cf38e52bb2ed852a5afd7a2f5497c6711243a02202aff5c3840b8a8fec710655a36ed931e7d3198cbaf0a7b1441d2726d1db73b4801 023ef1072fdaa98ac338d5c6d81dbbe5e3b04ba93ab264fabf1cfebcded3a0f79d",
"hex" : "483045022100e932e4cb29d6b6fd76dd943d162cf38e52bb2ed852a5afd7a2f5497c6711243a02202aff5c3840b8a8fec710655a36ed931e7d3198cbaf0a7b1441d2726d1db73b480121023ef1072fdaa98ac338d5c6d81dbbe5e3b04ba93ab264fabf1cfebcded3a0f79d"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 49000.98760000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 b9cad0c51435f495f3e97220f53585e581d34249 OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mxTLGQoK2sGQhtVMSe4qWZnb1nfC3QQHaL"
]
}
},
{
"value" : 999.01230000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 c35ecd1597c76829e5118f36033207795709b4bf OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"myKydMhECoFyY2iAWgwuEVbthej1sKHFdR"
]
}
}
],
"amount" : 999.01230000,
"confirmations" : 11,
"blockhash" : "000005fb04de17a44bcfc2195aed1878e890a1898799772a7fcf2e4dc80e1284",
"blockindex" : 1,
"blocktime" : 1402462748,
"txid" : "d0ce1a74c9e03fca3a507dfef2d0e7e8e6bc0b9b8180676a6fc481a275e0b670",
"time" : 1402462731,
"timereceived" : 1402462731,
"details" : [
{
"account" : "D2",
"address" : "myKydMhECoFyY2iAWgwuEVbthej1sKHFdR",
"category" : "receive",
"amount" : 999.01230000
}
]
}
|
|
|
|
Hello, I am the Supercoin dev, and I want to give an update to the community on our progress of the anonymous wallet work. First thanks to all for your patience. We've been working hard for a few weeks, and we almost finished the basic features, and they work fine. We are doing final dev testing. We will soon (in a few days) release a new version of the client (no hardfork) that will support anon features. But we want more tests to be done with the community, so for now we will only limit the anon feature in testnet environment. It will be the same client, but the anon features will be only allowed in testnet for now. We will decide, depends on how tests go, when the features will be in real network. So what is anon features? Anon features hide the traces of the transaction. So basically when you want to send from A to B, instead of showing in the blockchain explicitly a transaction showing A-B, it may show A->X, then Y->B, where X, Y are some random addresses (at least from a large address pool). Of course the transaction can be further obfuscated, such as you can split the sending amount to several parts, and apply the above for each part. This way, it is virtually impossible to trace the real transaction. So it protects your privacy. I will provide more details to our anon feature strategy and implementations later. And if you have questions, please post in the thread, the dev team will answer them as soon as possible (remember we all have our daily jobs, so please be patient ) |
|
|
|
|
Show Posts
