Is the smart bridge implemented? Any applications that use it? For ICO only for concept on the paper is not worth it. Yet there are many "investors" out there. Really a wild west culture, and I doubt who will actually make money. The dev certainly will. The rest good chance lol, it's a zero sum game.  |
|
|
|
|
Name: strasboug
Rank: Sr. Member
Post count: 334
Address: 1GXTm3JS4eHFjf8iVnz4SM4jTqPB284Uij
Wear Avatar and appropriate signature: Yes
|
|
|
|
|
Great work, and nice and fair way of distributions. The witness seem can be potentially a problem. I like DAG instead of fixed time blocks, DAGs are more flexible to handle huge amount of data.
|
|
|
|
|
User: strasboug
Position to Apply: Sr. Member
Posts Start: 332
Address: 1GXTm3JS4eHFjf8iVnz4SM4jTqPB284Uij
|
|
|
|
|
Not sure what is new in the ico coin. Sounds like zerocoin is just ported from coins like zcoin. Anything technically new and implemented?
|
|
|
|
|
interesting coin. does anyone know what's the advantage to use SHA224 as opposed to SHA256? Is it just a similar algorithm? or the dev choose it because it has some technical advantages?
|
|
|
|
nice... but we need an explanation or tutorial how to use these nodes. thanks. |
|
|
|
|
wow this is a nice coin, will follow...
i don't understand why the exchange wallet not working, as long as I send you the required verification amount, even my total amount is not accurate, you have no way to detect it, right?
|
|
|
|
looks like another get-rich-quick ico... man you need to have a more professional looking ANN and website if you want a successful ICO |
|
|
|
I see a lot of votes for Griffith and my vote goes there too.
I would really love to see supercoindev and strasbourg agree that a dev that is willing to learn the specifics of the code and work on it is better then no dev.
We really need supercoindev on board so he can give access to github and to all other stuff.
So i really hope he will agree with the communities choice.
I am willing to help as I can. As long as new dev willing to learn, it is always positive and should be no problem. I learned this as it goes, not that difficult especially the working code is already released there. |
|
|
|
yeah, i know, my initial review when i drew the diagram out on paper and made my first diagnostic of the coin was pretty far off, i made some looping mistakes and thought it was burning off coins by moving them around a lot. but the mixers didnt have the loop i thought they had and this turned out to be not true. that was so bad lol. so yes, i can admit when i thought there were loops in the mixers in this post: https://bitcointalk.org/index.php?topic=736705.msg9605259#msg9605259 i was wrong. i admit that. the second part was fine though. you can, as the code is right now, find the sender and receiver of the supersend transactions as i corrected myself in this post: https://bitcointalk.org/index.php?topic=736705.msg9615638#msg9615638 and that is completely correct your 2nd part is way off too, see above messages from marseille, strasboug, and many others. marseille, strasboug, supercoin, supercoindev all French, same English level ... . Could more than one be the same person? the intensity of the discussion was dying so ... I like Griffith and the way he behaves and reacts to accusations. He may not be Satoshi but all here accusing and attacking aren't Satoshi either. So, if I had a vote I would go with Griffith, at least until Satoshi turns up to help us  wouldnt be surprised if that was the case. considering some of the accounts were made within 30 min of each other. however, that proves nothing. lost in technical discussions now engage in a vicious personal attack? shame! yet you (all accounts) started with personal insults. and i didnt say you were all the same person. i said i wouldnt be surprised. please stop putting words into my mouth. Show *any* facts that these accounts from the same person?? Clearly you lost in the tech discussions now try to attack me and other people in person. You can think all the accounts that disagree with you are from one person, it doesn't matter, take whatever the stupid way you have for attacking, but - Does it change the fact that you have no idea on what is anon coin? No - Does it change the fact that you think multisig does nothing and why the coins transfer back and forth and make many people laugh at you? No - Does it change the fact that you understand nothing on the tech side and insist that you can guess the links using the tx amount, despite my earlier message on the same topic that you did not even read? No - Does it change the fact that you know nothing about the multisig and all the workflows that were published in the whitepapers by supercoindev long ago? No - Does it change the fact that you pretend to be an expert and made so many tech mistakes and caused so many people who understand the tech to post against you? No Everyone, by going through previous messages, will understand how much you know, and how much you pretend to know. The facts are there, everyone can see. Your attempt of attack will not change the facts. Like other people who understand, I don't need to spend more time arguing with you. You are exactly as what fastrabbit said "Ignorant is fearless", and stupid. |
|
|
|
yeah, i know, my initial review when i drew the diagram out on paper and made my first diagnostic of the coin was pretty far off, i made some looping mistakes and thought it was burning off coins by moving them around a lot. but the mixers didnt have the loop i thought they had and this turned out to be not true. that was so bad lol. so yes, i can admit when i thought there were loops in the mixers in this post: https://bitcointalk.org/index.php?topic=736705.msg9605259#msg9605259 i was wrong. i admit that. the second part was fine though. you can, as the code is right now, find the sender and receiver of the supersend transactions as i corrected myself in this post: https://bitcointalk.org/index.php?topic=736705.msg9615638#msg9615638 and that is completely correct your 2nd part is way off too, see above messages from marseille, strasboug, and many others. marseille, strasboug, supercoin, supercoindev all French, same English level ... . Could more than one be the same person? the intensity of the discussion was dying so ... I like Griffith and the way he behaves and reacts to accusations. He may not be Satoshi but all here accusing and attacking aren't Satoshi either. So, if I had a vote I would go with Griffith, at least until Satoshi turns up to help us wouldnt be surprised if that was the case. considering some of the accounts were made within 30 min of each other. however, that proves nothing. lost in technical discussions now engage in a vicious personal attack? shame! |
|
|
|
I really see no need a "dev" with no knowledge on this to "take over". Forget it, better let more comptent people like strasboug to take over, if he has time of course. Strasboug seems to understand details.
"Ghost" wallets to make it "harder" to follow. these are given away by not actually having a valid wallet generated super address. YES the address is a valid address. but it starts with a letter not S like all the other super addresses
1: CNCWvH4Bknr87a4PgDTRDasSxH4LnzX3iu
so whats the pattern? :
in a super block the "Ghost" wallet will have multiple outputs, and identical inputs. as you can see in example 1. it send out 66, 66, and 132 super coins. and then gets them right back...
-so whats the significance?
nothing. all it does is tell you in the amount that is shown twice, how much was sent in the SuperSend.
Please, don't make people laugh any more, do you have any knowledge about the multisig? You seem to be surprised that the multisig address starts with "C" and not "S", did you read anything in this thread? If you never read it, check the 2nd post of this thread, it has all the details and a detailed example. BTW, do you know for BTC the multisig address starts with which letter? (hint: not "1" of course). First you show people your understanding of "anon", now "multisig", will this end at all or you just want to continue to act like a joker?? Fastrabbit, thank you for the great summary of the tech used in supercoin and recommended me. Though I am very much interested in the tech and watch closely all the related development, I won't have enough time to take over as dev, as I know it is a commitment that needs a lot time. I admire supercoindev who did a perfect job before. Also, as many of us saw, supercoin still have many things to be improved. But, based on tx amount to guess the links and say supercoin is not anon is clearly wrong. As I mentioned in an earlier message, this is easily fixable and considered as nothing from tech point of view. From tech side, it is important to know if there's a systematic way to link the source to destination, and you can not do this in supercoin, so it is an anon coin, no question on it. For all other anon coins, you can do the same guessing, "guessing" is not an argument here. Griffith's understanding of supercoin tech seems at the novice level, with many concepts wrong/mixed, but from his messages he starts to understand some concepts. Everyone can learn. I was at novice level a year ago too, but now I understand it. BTW, the successfully use of multisig in supercoin is amazing, this opens a new door for the altcoins. I see several possible completion of the code in the error handling parts, as supercoindev mentioned. He could not finish all the coding, but with 1 months all the code working perfectly is a great achievement and showed his deep understanding of the problem and super coding skills. |
|
|
|
do a transaction and try to figure out the source, it is not difficult.
Isnt this the definition of not anon? Hoping you meant 'it is difficult' The system uses random nodes to create multisig address, so when there are enough participating nodes, you will not be able to pinpoint the source.
Or is this to say that when the supercoin network is large enough, the level of pseudoanonymity will be heightened. More potential random mixing nodes = higher difficulty in discerning sender. For the 1st thing I think supercoindev meant "it is not difficult to try a transaction and see whether you can find its source" For the 2nd, it is not easy to see the re-used multisig address, if the network is big enough. The supercoin transaction to the destination is sent through an address by mixer which does not even participate in the generation of the multisig address, therefore it is simply impossible to trace the source, as the mixer received his coins from a different one that participate the multisig address. For those who claimed that supercoin does not support anonymous transaction, I am 100% sure that they understand nothing about the code, nor do they understand the white papers. i said it wasnt anon and was just mixing very well instead. i fully understand the code and his use of the message command system. I don't think you get the code, see my comments above. Or, maybe we have different definitions about "anon", why not you state what is anon from your point of view? Mixing is one way to achieve anon as far as I understand. if i follow the richlist from person to person i can see who has what coins. for what i see, if there is anon in a coin. the richlist wouldnt be able to exist in such a way where you can see what wallets have most of the coins. lmao, richlist has nothing to do with anon. Anonymous coin does not mean you don't see wallet address and the coins under it. Anonymous coin means that in transferring coins you can't tell which is the source from the destination or vice versa. Therefore you can't trace the flow of the coins. Anonymity never intends to hide the wallet address and its balance. So it is ok to have richlist of a coin, as richlist does not mean anything, it simply shows balance of an address (and its transactions). A person can have 3 addresses belonging to him in the richlist, or have none in the richlist but he has most of the coins. I can have 10 addresses in the same wallet.dat with 10 mil SUPER yet each address won't have more than say 1.2 mil, no-one knows these addresses all belong to me (actually I can easily create 50 addresses under the same wallet.dat, I know someone has over 100 addresses in the same wallet.dat (to cheat some free distributed coins based on address) - as long as I partition the coins among them, the richlist will not show any address even I hold most of the coins). Even people know one address belong to me, as long as they can not trace where I send the coins to or what is the true source that send me coin, I have my privacy. |
|
|
|
do a transaction and try to figure out the source, it is not difficult.
Isnt this the definition of not anon? Hoping you meant 'it is difficult' The system uses random nodes to create multisig address, so when there are enough participating nodes, you will not be able to pinpoint the source.
Or is this to say that when the supercoin network is large enough, the level of pseudoanonymity will be heightened. More potential random mixing nodes = higher difficulty in discerning sender. For the 1st thing I think supercoindev meant "it is not difficult to try a transaction and see whether you can find its source" For the 2nd, it is not easy to see the re-used multisig address, if the network is big enough. The supercoin transaction to the destination is sent through an address by mixer which does not even participate in the generation of the multisig address, therefore it is simply impossible to trace the source, as the mixer received his coins from a different one that participate the multisig address. For those who claimed that supercoin does not support anonymous transaction, I am 100% sure that they understand nothing about the code, nor do they understand the white papers. i said it wasnt anon and was just mixing very well instead. i fully understand the code and his use of the message command system. I don't think you get the code, see my comments above. Or, maybe we have different definitions about "anon", why not you state what is anon from your point of view? Mixing is one way to achieve anon as far as I understand. |
|
|
|
|
Very nice supercoindev published the code. Thank you!
I went through the code quickly, well written code with a lot complex flows that I will try to understand later. Clearly supercoindev is an expert in multisig and he fixed code errors in the multisig related sections. The Bitcoin has the good multisig codebase, all rest altcoins except this one have the wrong code that certain multisig operations do not work.
Clearly the supercoin code support the anonymous transaction. The send address and receive address are not connected so can not be linked by looking at the explorer. One could try to use the tx amount to figure out the paths, such as if you send 1.234567 SUPERs and look in the explorer, you may be able to match unrelated addresses together. But if there are another tx with same amount, then it is absolutely not possible to figure out. Also, this issue can be fixed easily. I am sure supercoindev is aware of its solution and since he spent only 1 month on the coding, he likely did not have time to implement these minor features. By the way, this problem exist in almost all anon coins.
Fix is very simple: just break down the amount into "canonical" values. For example, we can have 1, 5, 10, 25, 50, etc as canonical values and the remaining part randomly split into 3 parts. So 27=25+1+1 and 42.25 = 25 + 10 + 5 + 1 + 1 + 0.11 + 0.06 + 0.08, and these split amount being sent each time. I saw some coins like DarkCoin claimed they did it, not tested it myself, but this is a common way. Also in the supercoin code supercoindev already implement the amount split algorithm, so this is almost noting to fix in the supercoin code.
Excellent job supercoindev, you are one of the very few devs in altcoins that are really competent!
|
|
|
|
Thank you dev for giving us an answer and choosing to release the code (hopefully sooner than later, so we can get this train moving). I to think supercoin will still have a future if this is the case. Like others have mentioned though, maybe release it to someone like Cryptobull first, as he has put in a lot for this coin. Then community can make decisions together on where to go next, it gives us a chance to try and get the code audited professionally before it is publicly released. That way supercoin can be known as the FIRST, before all the copy-cat coins. Perhaps open sourcing it will get us a free audit and publicity though? It hard to say.
Instead of donating to advertisement right now, maybe we should create a community bounty system soon?
New wallet design - xxxxx super
New website host - xxxxx super
etc
Also Dev, would you consider giving trusted community member access to official twitter/facebook accounts, or should we create new ones?
If we work together, and we have a code that can be improved upon, have the structure in place already (stakingwallets, blockchain, exchanges etc) we can make something out of this guys.
Forgive me if this has been covered, but I must play devil's advocate. Do we know who Cryptobull is beyond this thread? Is he someone trustworthy of wielding the Super Sword? What's to say he doesn't keep the code to himself as well or release a copycat himself? Opportunity can do strange things to otherwise seemingly good-willed individuals. Cryptobull, I mean no slight to you, I simply want to try and determine a safe way to migrate this Closed -> Open transition. With only 1 party (other than Superdev & team) in control of the source, we risk being in the same situation that we are in now. I do not wish for this to happen. Community, are my thoughts being over cautious? Would handing the code over to a group of Super community members mitigate this risk? Or perhaps if there is an auditor we can agree on that the code get released to only Cryptobull & the auditor simultaneously...this ensures the community that the source is within reach & that the Supercoin is the first coin audited & recognized for fully trustless decentralized multisig. It may give us the exposure oppurtunity to shop for a top level dev to move forward with the project. Any other thoughts folks? lol CryptoBull is fine dont worry about him hes a very good guy, maybe too much of a good guy for supercoindev and supercointeam. Dont claim victory, we don't have the source code yet. They said "by the end of the month", this means no answer for another 2-3 weeks. I'm sorry but supercointeam/supercoindev are the perfect example of the crooks and shitty dev everybody have been complaining on the crypto market for the last few months. When I saw some users having trouble with the new wallet in august with the price 2500sat, I sold pretty much everything but I still had doubts, so I couldn't tell everyone I knew to sell SUPER. I know a lot of friends with big losses on SUPER, these guys should be ashamed of themselves and release the source code tonight. Then, leave the crypto market forever. Nobody want to see them on another project. Yes I believe in a SUPER takeover with the community and the source code, this is the only 2 good things about Supercoin.One reason the dev left is because in this space there are too many bullshits like you. Open your eyes and see how much work dev did for this coin, and be thankful. And as a comparison how many complaints you made. If people just make complaints and not take initiatives, nothing will be happening. Look at yourself and think if you really want to help the coin, what you should do, instead of blaming devs. Dev did excellent job. If I were the dev I'd be very disappointed by the dismal performance of this coin. It is not because of the great tech the dev spent countless hours to implement and promote (just look at the whitepaper and you know how much time they spent there, let alone the coding/debugging). I doubt there are qualified people to take over the code. These high fly coins are not because they have advanced tech, but because they have good promotions. They have 10, 20 people just doing promotions. That makes the diffs. Most of their devs don't even know what is multisig. Just look at the threads of discussion with cloak and XC and judge yourself if these "devs" know anything (links below), it is a joke. https://bitcointalk.org/index.php?topic=734578.0https://bitcointalk.org/index.php?topic=742025.0 |
|
|
|
this is true. Another point is that the malleability issue is caused by malformed signature in transaction, while a simple check to disallow it will fix the issue. this problem already fixed in BTC 0.9. I don't think this is an issue for multisig based trustless system.
No, malleability doesn't lead to a malformed signature. A malformed signature would be invalidated by virtue of it being malformed. With a traditional Bitcoin malleability attack you change the signature format on a tx and rebroadcast it, but the signature remains perfectly valid. The bulk of the anti-malleability changes in 0.9.0 are around things like listreceivedbyaddress or getbalance or listtransactions RPC API calls to make them less error-prone. There is a slight tightening of IsStandard() to make rebroadcast of modified transactions harder, but all that implies is that an attacker needs to have a bunch of nodes and some mining power in order legitimise his transactions. It's also a given (see the Satoshi quote) that txid's can change during a reorg. They are not - ever - meant to be relied on, as they are not canonical. OK I don't really think this is an issue. Let me see what are the issues you have. From what I understand, this is the main one: - transfer txid around can be a problem sometimes, as with malleability it changes sometimes Do you have other issues? I saw you mentioned guarantor, what exactly the issues you have? I am not the dev of Supercoin, he can jump in and answer your question. But let me try to answer it with my understanding of the algo they use. For malleability issue, 0.9 fix prevents mutated txid from being relayed etc, it also try to accept only the standard sig format. By malformed, I meant "non-standard", not the "malformed" in the sense of basic format, of course it was not caught before, otherwise we won't have the issue of malleability. With these fixes in 0.9, it should not be an issue. But even it is an issue and if Supercoin used a non-sync'd version with 0.9, there are ways to solve the problem, for example to scan the tx from a time on to find the related tx. My understanding is that they (each party in the trustless transaction) need to verify two things before proceeding to the next step: 1. Everyone deposited to escrow (multisig address), and with proper amounts. 2. Mixer has sent the amount to the destination. For (1), people does not really need txids. Because after all parties deposited, and notified other parties, each party can just check the multisig address, which is notified to all parties earlier (so that they can make deposit). It is easy to check what amounts have been deposited and by which address. So for this verification, you don't need txids. For (2), after Mixer notified the other two parties, it is possible to scan the blockchain for all tx after certain timestamp, and match txin's address with that of Mixer. This will not be difficult as there are limited blocks after the timestamp. From what I see the demo and test in Mammothcoin, it usually pretty fast (5 sec) before the block containing tx is sync'd to each other's wallet. What I mean is that you don't have to rely on the txids to do the verifications. The overall algorithm for exchange info and data is pretty standard in the trustless marketplace of buyer-seller-mediator scenario which I believe is perfect solid. So no further comments. I don't see any problem of supercoin's algo, now that they released the client, works fine as far as my tests go. |
|
|
|
this is true. Another point is that the malleability issue is caused by malformed signature in transaction, while a simple check to disallow it will fix the issue. this problem already fixed in BTC 0.9. I don't think this is an issue for multisig based trustless system.
No, malleability doesn't lead to a malformed signature. A malformed signature would be invalidated by virtue of it being malformed. With a traditional Bitcoin malleability attack you change the signature format on a tx and rebroadcast it, but the signature remains perfectly valid. The bulk of the anti-malleability changes in 0.9.0 are around things like listreceivedbyaddress or getbalance or listtransactions RPC API calls to make them less error-prone. There is a slight tightening of IsStandard() to make rebroadcast of modified transactions harder, but all that implies is that an attacker needs to have a bunch of nodes and some mining power in order legitimise his transactions. It's also a given (see the Satoshi quote) that txid's can change during a reorg. They are not - ever - meant to be relied on, as they are not canonical. OK I don't really think this is an issue. Let me see what are the issues you have. From what I understand, this is the main one: - transfer txid around can be a problem sometimes, as with malleability it changes sometimes Do you have other issues? I saw you mentioned guarantor, what exactly the issues you have? I am not the dev of Supercoin, he can jump in and answer your question. But let me try to answer it with my understanding of the algo they use. For malleability issue, 0.9 fix prevents mutated txid from being relayed etc, it also try to accept only the standard sig format. By malformed, I meant "non-standard", not the "malformed" in the sense of basic format, of course it was not caught before, otherwise we won't have the issue of malleability. With these fixes in 0.9, it should not be an issue. But even it is an issue and if Supercoin used a non-sync'd version with 0.9, there are ways to solve the problem, for example to scan the tx from a time on to find the related tx. My understanding is that they (each party in the trustless transaction) need to verify two things before proceeding to the next step: 1. Everyone deposited to escrow (multisig address), and with proper amounts. 2. Mixer has sent the amount to the destination. For (1), people does not really need txids. Because after all parties deposited, and notified other parties, each party can just check the multisig address, which is notified to all parties earlier (so that they can make deposit). It is easy to check what amounts have been deposited and by which address. So for this verification, you don't need txids. For (2), after Mixer notified the other two parties, it is possible to scan the blockchain for all tx after certain timestamp, and match txin's address with that of Mixer. This will not be difficult as there are limited blocks after the timestamp. From what I see the demo and test in Mammothcoin, it usually pretty fast (5 sec) before the block containing tx is sync'd to each other's wallet. What I mean is that you don't have to rely on the txids to do the verifications. The overall algorithm for exchange info and data is pretty standard in the trustless marketplace of buyer-seller-mediator scenario which I believe is perfect solid. |
|
|
|
|
Show Posts
