Hopefully we will have some respected people review the code. There are still some attack vectors if you don't take precautions with your amounts and timing. For example, you transfer 27.75664321 SDC to Shadow. Then 5 minutes later u turn the exact same amount less the fee back to SDC, its going to be pretty obvious.
That would be circumstantial evidence which as far as I'm aware is not the irrefutable evidence that is needed compile a dead cert case. If the person is worried about said circumstantial evidence then he / she would probably take the simple precautions to ensure that wouldn't happen. i.e waiting more than 5 minutes by holding shadow for a longer time period in advance and not swapping the exact same values.
|
|
|
Technically speaking, it'd be interesting for the dev team to run a testnet simulation to check anonymity and bloat / scaling impact, as well as spam attack vectors against the blockchain.
There were performance tests mentioned in section 5 of the whitepaper: 5. Performance 5.1. Proof Sizes The affine coordinates are 64 bytes per ring member per coin value. We store the public key or keyImage, which is 33 bytes That leaves us with ~97 bytes / ring member / input 5.2. Benchmarks The following benchmarks were done on an Intel(R) Core(TM) i73537U CPU @ 2.00GHz with 8GB of RAM, using the average times out of 300000 iterations: Algorithm Ring members Average Time Average time / ring member Signing 200 449ms 2.25ms Verification 200 440ms 2.2ms
|
|
|
Just did a quick google search and found an interesting Bitcoin wiki about scalability. https://en.bitcoin.it/wiki/ScalabilityScalability targets
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 47,000 tps. [1]
PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps. [2]
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.
Network
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.
|
|
|
Confirmation times aside, already been well explained in the OP... I read a comment today that mentioned Visa can do 100,000 transactions per second whilst Bitcoin is capped at 7 max per second. On that basis btc would allow for max 400 (approx) transactions per minute and 604800 per 24 hours. Just wondering what peoples thoughts are on this (perhaps it's not even true)? http://pastebin.com/Vf6XkDm3
|
|
|
IDEA:
Moving all into Shadows seems the way to go.
Wouldn't that effectively make us a cryptonote coin? I think having the best of both worlds (which we have right now) is ideal.
|
|
|
Consider that you take 53,17 SDC, convert it to shadow, send it to someone (for example to pay for a private purchase), and soon thereafter he converts it back to 53.17 SDC. During which time there hasn't been a whole lot of activity (certainly no other transactions in that same amount or close to it). Is this really fooling anyone?
Thank you smooth. Most gracious of you to come in here and discuss the tech. I'd like to focus on this part of your reply. It seems like an obvious weakness which the devs must have considered. Certainly even my non-tec brain could savvy ways to obfuscate the the coin state change. The user could determine the time/amount of conversion or this could occur ina randomised way or perhaps it never need happen at all?! An obvious solution that exists right now to this "statistical analysis" theory of matching inputs to outputs would be to simply hold a certain amount of Shadow Token in advance and moreover a different amount than that being sent for the anon transaction (that somebody may wish to track). By waiting before sending after conversion you are therefore increasing the time and activity between the conversions which would be fooling enough by most standards.
|
|
|
Merry Christmas SDC community!
|
|
|
Quick shadow question: How do you convert your Shadow to SDC in your wallet? I can't find a button for that.
I've been able to convert (in wallet) Shadow to SDC by sending Shadow to one of my stealth addresses using the same technique from the following vid (minus the secondary wallet). Demo 3:Shadow to SDC https://mega.co.nz/#!TdVkjADT!lMZgQPl89T8NW1T12a7CRHZNbn88-RqqnXhTuj9YSQMOnly the fees appear visible in the transaction history if you send to self however you can verify the success of the conversion by noting balances in Shadow and SDC beforehand. ************* Is Alty being part of the SDC team? He is such a big threat for the crypto community. He fucked several crypto investors with his big scam Cloakcoin. Hype, empty promises, broken incomplete code, insider trading and then disapperead.
************* I have nothing to do with the SDC team I just try to help out where I can. While we are on the subject; Cloakcoin was never a scam. Anon via exchanges worked as did trading in wallet to an exchange. Both a first. It had unfinished code yes because the coders didn't have time or funds to finish properly given the constraints imposed by the market following the dumping. DRK has been broken over and over and yet they've somehow been able to keep their head above water... unfortunately that luxury is very rare. As for broken promises... I wasn't the coder... I just did my job of representing the coin and promoted the concepts that the devs presented to me.
|
|
|
First off, has there been enough time to assess if ShadowCash project has a working Zero Knowledge solution?
I haven't looked at the code. From the white paper it looks like it has what you are calling a "Zero Knowledge solution" based on the methods from cryptonote. Secondly, does the Monero project of Darkcoin project have a Zero Knowledge solution?
Monero and Darkcoin are different projects. Monero uses cryptonote, so it has what you are calling a "Zero Knowledge solution" (and has had it since day one, in April 2014). Nobody outside of the SDC community calls it that, but you can use whatever terminology you like I suppose. Cryptonote (i.e. Monero) does use a simple zero knowledge proof in its signature scheme, the same method that SDC uses. Darkcoin uses a variation of coinjoin where inputs and outputs from various transactions are combined by a series of semi-trusted nodes called Masternodes, essentially mixing those transactions together. There is not really a special transaction type for this, just a regular bitcoin-style transaction with many inputs and outputs. I'd like to compare anonymous transactions between the three projects being discussed here; XMR, DRK & Shadow. Could somebody post transaction IDs for each project showing an anonymous trade? I'd like to compare apples to apples when it comes to linkability and traceability. Ignoring codebase and proof differences between them for now.
Here is a Monero transaction: http://chainradar.com/xmr/transaction/ab187945caff3a9ca5034338657808f242d8f2899fc11d93f2ef2d719bb16ecdI don't know enough about the others to provide correct links to anonymous transactions. What many people seem to be missing (and it is totally normal to do so because it's not been seen before) is they keep comparing it to existing solutions. SDC has something completely new in that it destroys coins that are then converted into redeemable tokens that sit on top of the blockchain and these tokens can then be reconverted via minting into new SDC.It's only the exchange / allocation of tokens that use the ring sig with basic NIZK to prove to the blockchain that the holder owns the value of the output without revealing identity, it's not the actual coins using ring sig. It is indeed a very well thought out system that cannot be followed on an explorer because it'll just lead you to a dead end. Hence 100% anon.
|
|
|
First off, has there been enough time to assess if ShadowCash project has a working Zero Knowledge solution?
Secondly, does the Monero project of Darkcoin project have a Zero Knowledge solution?
I'd like to compare anonymous transactions between the three projects being discussed here; XMR, DRK & Shadow. Could somebody post transaction IDs for each project showing an anonymous trade? I'd like to compare apples to apples when it comes to linkability and traceability. Ignoring codebase and proof differences between them for now.
If there are other working ZK solutions in projects I haven't mentioned that should be part of this comparison please add an anonymous transaction from them as well.
1 good example from each blockchain would be appreciated.
Thanks.
Today I will release a demo video showing the SDC anon transaction happening in real time between two wallets and analysing the block explorer at the same time.
|
|
|
Hats off to the devs of ShadowSend v2
Testing has proved that conversion from SDC > Shadow, Shadow > Shadow and Shadow > SDC works flawlessly on mainnet. Transactions happen very quick and they are completely unlinkable on the blockchain.
Finally a way to transact privately and securely.
Ryno and Technovert working on SDC = Masters of The Coin 2015
|
|
|
i am asking about copy paste? Dev mention that about future plan, so where is unique code?
I believe it's called a reference?...hence the reference number to the paper.
|
|
|
1st RECALL vid posted earlier on Twitter.Building the foundations / infrastructure and general communication from the Joe (Sapience / Quotient dev). www.youtube.com/embed/xikDdBYkJfg
|
|
|
coin-swap.net is a shit exchange, I never use it Oh well goodbye coin-swap!
|
|
|
The Fujisaki paper is basis for traceability in cryptonote ring signatures. The shadow token paper clearly describes a trusted ("special") setup to create an oracle as two hash functions. It is a deal breaker for true anonymity because it requires you to trust the person who set it up.
This is the exact same problem with all "zero coins". They require a trusted setup.
From my understanding... SDC's implementation is different from standard "zero coin" ZK attempts in that it utilises ZK in a way that the "setup" is similar to a dev who sets up or generates the genesis block. In the SDC version of "ZK" it appears (to me at least, please correct if wrong) that SDC v2 only uses "ZK" to obfuscate the minted tokens exact origin whilst being able to prove their existance and therefore validate their redemption when passed on / spent. It appears that the natural randomization of progressive use through multiple outputs (exchanging SDC for Tokens and vice versa) would signify that obtaining any kind of relative gain from knowing how it was "setup" if it was indeed relevant completely obsolete. Still am trying to get to grips with this and would like to learn more but my conclusion so far is the "setup" you refer to and the way it's used in SDC's case is a bit like Satoshi "setting up" the Bitcoin genesis block.... It's relevant to a point of not being relevant once it's out because the coins on the blockchain don't lie and SDC coins will always be accounted for. Not sure I understand how it would matter for this particular use?
|
|
|
|