Author

Topic: rpietila Altcoin Observer - page 130. (Read 387493 times)

hero member
Activity: 518
Merit: 521
July 28, 2014, 11:28:54 AM
Could you tabulate that summary so that the items are the same for each currency you list. A + when supported and a - when not.

I will let someone else edit. This is open source.
sr. member
Activity: 294
Merit: 250
Bitmark Developer
July 28, 2014, 11:26:41 AM
Could you tabulate that summary so that the items are the same for each currency you list. A + when supported and a - when not.
hero member
Activity: 518
Merit: 521
July 28, 2014, 11:17:44 AM
Would like to get some closure on recent discussions.

To help rpietila with the periodic summaries he typically adds to the OPs of his moderated threads, I suggest we try to compile a summary of the significant pluses and minuses of top anonymous coin designs.

Could we agree on wording such as the following? Please let me know if I left anything out that we discussed upthread. The following doesn't attempt to qualify how likely or predominant relative weaknesses are, as this is too complex to summarize succinctly.

* represents a feature which is claimed to be an advantage but may or may not be a liability.
?? means I guessed and am not sure.

Monero (Cryptonote coins)

+ cryptographically unlinkable & untraceable
- tx sybil attack (mitigated with mandatory tx fees)
- I2P (anonymity or DoS) sybil or timing analysis attack
- unprunable -> mining centralization or less scalable
- public key cryptography not quantum nor number theoretic immune
- slow PoW hash
- mining is not anonymous
* unvetted asic-resistant PoW hash, demonstrated GPU parity

Boolberry (Cryptonote optimization)

+ discards ring signatures reducing block chain size by a constant factor
+ prevents mixing with those who don't mix so unlinkability & untraceability isn't trivially broken
+ cryptographically unlinkable & untraceable
- tx sybil attack (mitigated with mandatory tx fees)
- no I2P/Tor IP obfuscation
- unprunable -> mining centralization or less scalable
- public key cryptography not quantum nor number theoretic immune
- mining is not anonymous (??)
* unvetted asic-resistant PoW hash, demonstrated GPU parity (??)

DarkCoin (this is the best CloakCoin's anonymity could improve to as it is similar conceptually in design)

+ prunable (but unimplemented)
- unlinkability Sybil attack on masternodes
- tx sybil attack (mitigated with mandatory tx fees)
- Tor (anonymity or DoS) sybil or timing analysis attack
- simultaneity or premix tx bloat -> mining centralization or less scalable
- public key cryptography not quantum nor number theoretic immune
- mining is not anonymous (??)

Zerocash

+ all coins mixed all the time, so no tx Sybil attack incentive (may not need tx fees if they adopt my secret??)
+ don't need to obfuscate IP address (I2P/Tor) because...
+ ...everything is cryptographically hidden...
- ...even the money supply -> compromised master setup or cryptanalysis breakage could create unlimited undetected coins
- unprunable (??) -> mining centralization or less scalable
- public key cryptography not quantum nor number theoretic immune
- unvetted new complex crypto could break anonymity and coin value retroactively
- mining is not anonymous (??)
- not released
hero member
Activity: 518
Merit: 521
July 28, 2014, 10:48:23 AM
Since new addresses are free, why not...?

Hint: yeah the more the better. Wink
hero member
Activity: 518
Merit: 521
July 28, 2014, 10:43:10 AM
I assume you mean relay nodes sending out dummy packets at random intervals, so latency doesn't increase for legitimate traffic (as long as relay nodes can handle the additional bandwidth).

I have been thinking about establishing fixed capacity channels between sets of nodes instead. The negotiated capacity is filled completely at all times, either with padding or real data. Because channels are encrypted, an attacker cannot differentiate between them.

The user's packet has to be in the same form as it entered the network when it leaves the network going the miner. Afaics, your proposed cover channels accomplish exactly nothing.
If your threat model includes the attacker looking at clear traffic on both sides, you have lost anyway, because the attacker can already read the transactions senders send and know who the senders are. Otherwise, the attacker cannot tell the way the packet looked when the sender sent it,

Correct (I had momentarily forgotten the logic of my original post to which you replied), the onion routing encryption layers are peeled off, thus the no knows the unencrypted data the sender sent until it arrives at the last node in the network which doesn't forward it.

However, this doesn't stop the adversary from looking at unencrypted data the miner is receiving, thus determining which data was cover (dummy) traffic.

Yet the spender could encrypt data for the miner, so only if the miner was compromised would your idea fail. The uncompromised miner would discard dummy packets and no one would know which they are.

Which is another reason we don't want mining to be centralized  because it is more likely the fewer mining pools will be compromised.

But I don't see how cover channels can even work as you describe them? Where does the constant flow originate in onion routing?


Please understand that this proposal is intended to counteract opaque timing attacks only, not sybil attacks.

Why do you mention that? Even if you Sybil attacked the entry node, you wouldn't know what the destination packet looks like due to the onion routing.

Sybil attacks are very hard to defend against...Despite all, in 2012 the NSA was still obstructed in some degree by even Tor use. The least we can do is make it a bit harder for them.

A Sybil attack doesn't mean you succeed 100% of the time, as you don't have 100% of the relay nodes.

I want anonymity by needle-in-haystack, not anonymity by pair of dice.

Apparently nobody knows what percentage level of relay nodes the NSA controls on Tor (or I2P).

I entreat you to stop mentioning Tor. It is a different system than I2P, which is being implemented.

It is still a haystack, just of different size. It is still better than nothing at all. A hypothetical attacker with infinite budget cannot be defeated. We can model an attacker with specific capabilities and attempt to design system which defeats the attacker with a given probability. We do not actually disagree on this?

My point is that 10-20% of the relay nodes Sybil attacked is not needle-in-the-haystack odds, more like the odds of flipping a dice or pair of them.
hero member
Activity: 910
Merit: 1003
July 28, 2014, 10:30:39 AM
Personally, I do not see transaction fees as a problem. I believe that fees should be enforced in every single coin. No fees = bloating attack vector open = coin is DOA
Indeed, I got this suspicion that most of the traffic in the Bitcoin blockchain (~70'000 BTC/day currently) is "fake", namely coins being moved between addresses that belong to the same owner.   Could it be all generated by a single person, from a single laptop, moving 500 bitcoins (possibly in many different addresses) every 10 minutes or so?  Perhaps someone is trying to wash stolen coins, or torture-test some wallet software...
https://blockchain.info/charts/estimated-transaction-volume 

The number of new addresses used per day may be bloated for the same reason.  Since new addresses are free, why not...?
newbie
Activity: 16
Merit: 0
July 28, 2014, 10:21:57 AM
I assume you mean relay nodes sending out dummy packets at random intervals, so latency doesn't increase for legitimate traffic (as long as relay nodes can handle the additional bandwidth).

I have been thinking about establishing fixed capacity channels between sets of nodes instead. The negotiated capacity is filled completely at all times, either with padding or real data. Because channels are encrypted, an attacker cannot differentiate between them.

The user's packet has to be in the same form as it entered the network when it leaves the network going the miner. Afaics, your proposed cover channels accomplish exactly nothing.
If your threat model includes the attacker looking at clear traffic on both sides, you have lost anyway, because the attacker can already read the transactions senders send and know who the senders are. Otherwise, the attacker cannot tell the way the packet looked when the sender sent it, because from the side of the sender the attacker only sees say 100 packets per second of constant size sent to 16 different nodes each, which also behave this way.

Please understand that this proposal is intended to counteract opaque timing attacks only, not sybil attacks.

Sybil attacks are very hard to defend against...Despite all, in 2012 the NSA was still obstructed in some degree by even Tor use. The least we can do is make it a bit harder for them.

A Sybil attack doesn't mean you succeed 100% of the time, as you don't have 100% of the relay nodes.

I want anonymity by needle-in-haystack, not anonymity by pair of dice.

Apparently nobody knows what percentage level of relay nodes the NSA controls on Tor (or I2P).
I entreat you to stop mentioning Tor. It is a different system than I2P, which is being implemented.

It is still a haystack, just of different size. It is still better than nothing at all. A hypothetical attacker with infinite budget cannot be defeated. We can model an attacker with specific capabilities and attempt to design system which defeats the attacker with a given probability. We do not actually disagree on this?
sr. member
Activity: 294
Merit: 250
Bitmark Developer
July 28, 2014, 10:12:41 AM
And I need that to become open source asap, because it is dangerous to hold such a secret and not tell anyone.

Often the way to approach this problem, is to develop and create openly from the start. You can easily develop publicly and test before launch whilst building a conversation with no negative impact on the community or the thing being developed.
hero member
Activity: 518
Merit: 521
July 28, 2014, 10:07:22 AM
Both can't avoid transaction fees because their anonymity depends on mixing transactions which encourages transaction spam.

Personally, I do not see transaction fees as a problem. I believe that fees should be enforced in every single coin. No fees = bloating attack vector open = coin is DOA. Nobody wants to use coins which have terabytes of blockchain because some kid scripted bogus transactions for the lulz / just to kill a coin. Such a coin would be a joke coin. Why would anybody use a joke coin that can be bloated to destruction by script-kids, at no cost?

If I answered that, I would reveal one of my valuable secrets. Not even people I speak to privately know my answer to that.

And I need that to become open source asap, because it is dangerous to hold such a secret and not tell anyone.
hero member
Activity: 518
Merit: 521
July 28, 2014, 10:03:02 AM
If mining is centralized then the exit points are probably easy to find.

Neither are there exit nodes, nor are transactions sent directly to miners. Transactions are broadcast through the whole network. How do known miners make it easier to perform traffic analysis in a cover traffic scenario?

The adversary could hijack the upstream router/ISP of the miner and peer at all traffic incoming to the miner.

I assume you mean relay nodes sending out dummy packets at random intervals, so latency doesn't increase for legitimate traffic (as long as relay nodes can handle the additional bandwidth).

I have been thinking about establishing fixed capacity channels between sets of nodes instead. The negotiated capacity is filled completely at all times, either with padding or real data. Because channels are encrypted, an attacker cannot differentiate between them.

The user's packet has to be in the same form as it entered the network when it leaves the network going the miner. Afaics, your proposed cover channels accomplish exactly nothing.

Sybil attacks are very hard to defend against...Despite all, in 2012 the NSA was still obstructed in some degree by even Tor use. The least we can do is make it a bit harder for them.

A Sybil attack doesn't mean you succeed 100% of the time, as you don't have 100% of the relay nodes.

I want anonymity by needle-in-haystack, not anonymity by pair of dice.

Apparently nobody knows what percentage level of relay nodes the NSA controls on Tor (or I2P).
legendary
Activity: 1708
Merit: 1049
July 28, 2014, 09:57:21 AM
Okay so compared to Monero (Cryptonote), DarkCoin has an additional Sybil attack vector yet also can have prunability which Cryptonote can't.

Which is the difference between having a usable anonymous coin and a proof-of-concept coin until the scaling can be resolved.

Quote
The argument is made that these masternodes won't be easily Sybil attacked because only a whale could. Your argument against the possibility of owning a lot of nodes fails due to the fact that money is always power law distributed[1]. One can argue that whales wouldn't destroy their investment by attacking it, but whales can be coerced with rubber hose or offered a percentage of the booty gained. Wink

Actually, the game theory component of Darkcoin seems quite solid. And remember that DarkSend, when opensourced, can be used in multiple coins - which means that suddenly, one must have A LOT of money to own the nodes of every single coin out there, to deanonymize everything. It also creates the following loop:

Coin implements DarkSend => The-powers-that-be need to buy 80-95% of the nodes to deanonymize a good percent of transactions with 8 rounds of DarkSend => buyers of said coin get rich by TPTB that buy from them.

Suddenly you've made a mechanism where ordinary people are getting rich by the NSA or NSA-equivalent organizations. This is a non-strategy for the elite. They want to track you but not to make you rich - or ensure that every buyer of DarkSend-enabled coin will get rich.

The forceful or coerced cooperation part is also doubtful since nodes are all over the world. It's not enough to have a few nodes. You need a lot of nodes. And even if you have a lot of nodes, a paranoid Darkcoin user will escape detection by laundering his money 2-3-4 (or more) times over 8 different nodes (total 32 nodes) - by paying the fees necessary of course. The statistic possibility of deanonymizing him by going over 32 (or more) nodes would be near zero.

I am more worried about the IP obfuscation part of anonymous coins, rather than sybil attacks in Darkcoin / DarkSend-enabled coins. That's the weak spot.

Scaling, I believe, is a no-issue, not only due to pruning, but also due to lower-settings of mixing that will be used for less paranoid users that are more concerned with privacy rather than total anonymity.

Quote
Both can't avoid transaction fees because their anonymity depends on mixing transactions which encourages transaction spam.

Personally, I do not see transaction fees as a problem. I believe that fees should be enforced in every single coin. No fees = bloating attack vector open = coin is DOA. Nobody wants to use coins which have terabytes of blockchain because some kid scripted bogus transactions for the lulz / just to kill a coin. Such a coin would be a joke coin. Why would anybody use a joke coin that can be bloated to destruction by script-kids, at no cost?
legendary
Activity: 1512
Merit: 1012
Still wild and free
July 28, 2014, 09:45:17 AM
The argument is made that these masternodes won't be easily Sybil attacked because only a whale could. Your argument against the possibility of owning a lot of nodes fails due to the fact that money is always power law distributed[1].

Note that in the case of a ninja-mined currency, you don't even need to bring the general wealth distribution to the table to break the assumption that Sybil attacks cannot happen in practice.
newbie
Activity: 16
Merit: 0
July 28, 2014, 09:40:25 AM
If mining is centralized then the exit points are probably easy to find.
Can you please explain this in more detail? Neither are there exit nodes, nor are transactions sent directly to miners. Transactions are broadcast through the whole network. How do known miners make it easier to perform traffic analysis in a cover traffic scenario?

I assume you mean relay nodes sending out dummy packets at random intervals, so latency doesn't increase for legitimate traffic (as long as relay nodes can handle the additional bandwidth).
I have been thinking about establishing fixed capacity channels between sets of nodes instead. The negotiated capacity is filled completely at all times, either with padding or real data. Because channels are encrypted, an attacker cannot differentiate between them.

Seems to me the adversary could ignore all packets coming out of the exit nodes that didn't correlate with a low-latency to the targeted entry node.
Again: There are no exit nodes with I2P. This is also not possible with fixed bandwidth cover traffic channels.

Sybil attacks are very hard to defend against if your attacker can replace your internet connection with connection to NSA LAN instead. Despite all, in 2012 the NSA was still obstructed in some degree by even Tor use. The least we can do is make it a bit harder for them.
hero member
Activity: 518
Merit: 521
July 28, 2014, 09:36:26 AM
Okay so compared to Monero (Cryptonote), DarkCoin has an additional Sybil attack vector yet also can have prunability which Cryptonote can't.

The argument is made that these masternodes won't be easily Sybil attacked because only a whale could. Your argument against the possibility of owning a lot of nodes fails due to the fact that money is always power law distributed[1]. One can argue that whales wouldn't destroy their investment by attacking it, but whales can be coerced with rubber hose or offered a percentage of the booty gained. Wink CloakCoin's anonymization stage has the similar Sybil attack vector. Additionally other game theory that is not yet considered.

Being prunable, DarkCoin could in theory scale better on the block chain size but it increases the level of unnecessary transactions which impacts other aspects of scaling. Increasing the masternode stages from 2 to 8 exacerbates this further. So it is doubtful either can scale without centralized mining, and at least Monero doesn't have one (of the three) Sybil attack vectors.

Both can't avoid transaction fees because their anonymity depends on mixing transactions which encourages transaction spam.

[1] A. Dragulescu and V. Yakovenko. Exponential and power-law probability distributions of wealth and income in the United Kingdom and the United States.
legendary
Activity: 1708
Merit: 1049
July 28, 2014, 09:15:04 AM
https://darkcointalk.org/threads/development-updates-july-7th.1735/

The DarkSend+ anonymity depends on MasterNode1 and 2 are not Sybil attacked in order to achieve unlinkability and untraceability, and adds some of the blockchain bloat of Cryptonote. Cryptonote (Monero) achieves that without any such Sybil attack threat.

In the later update (mid-July), it goes up to 8 nodes - not 2. So the probabilities are far better.

Remember there is a dis-incentive to Sybil by requiring 1000 DRKs per node. And you can't buy a lot of nodes without taking the price to the sky, as the less DRKs there are in the market, price increases non-linearly. So you'll need to own a heck of a lot of nodes to Sybil this - and the money required to increase your success percentage are going up in a non-linear fashion during the accumulation of DRK nodes.

Personally I think premixing is quite interesting because, aside from solving issues that occur in realtime (like the simultaneous tx / denomination requirement) it re-opens the possibility of blind sigs... As it is right now (the implementation of DRK's coinjoin), it is performed without blind signatures due to the DOS issue that blind sigs had - which you discussed with Evan. So the node does know in order to be able to penalize bad behavior. But with premixing, the requirement for real-time coinjoin is eliminated... so, I'm thinking, perhaps, blind sigs can be used for better mixing. Even if mixing fails due to DOS, it is not a problem as a retry can be initiated for many times. It's all in the premixing phase (that could be days before a transfer) and thus one has plenty of time to waste... it could probably be activated with a "paranoid" checkbox for those desiring blind-sig level of anonymity.

Quote
Continuous mixing won't scale, because it explodes the transactions by some square law. So if you think the scaling calculations I showed for Monero were egregious when scaled to Visa scale, get out your calculator and run them on this DarkSend premix idea.  Shocked

It is comical to watch them tack on multiple layers of duct tape on a fundamentally flawed algorithm.

Remember that Darkcoin, unlike Monero, can be pruned.
hero member
Activity: 518
Merit: 521
July 28, 2014, 09:09:44 AM
Continuous mixing won't scale

Can it be pruned?

In addition to the block chain bloat, you've also got the transaction volume scaling up by some additional factor because generating Visa scale volume causes all these premix transactions for that volume. This impacts the size of the UXTO, block size, verification time, etc factors which impinge on centralization of mining. The mini blockchain won't help you scale down unnecessary transaction volume.

And that the anonymity relies on mixing transactions (inputs) means there is an incentive (for both spenders wanting anonymity and the adversary trying Sybil attack) to explode the level of transactions to Sybil attack the anonymity. So then you've got to have transaction fees.

Can mini-blockchain be implemented on it - and if so, how big of a task would it be? Trivial, moderate, large, monumental?

In theory yes. They could try to fork Cryptonite (not Cryptonote) and apply DarkSend to it.
hero member
Activity: 644
Merit: 500
July 28, 2014, 09:02:33 AM
Did anyone of you buy Ether, and if you did, why?
hero member
Activity: 966
Merit: 1003
July 28, 2014, 09:02:04 AM
Continuous mixing won't scale

Can it be pruned?

Can mini-blockchain be implemented on it - and if so, how big of a task would it be? Trivial, moderate, large, monumental?
hero member
Activity: 518
Merit: 521
July 28, 2014, 08:49:33 AM
https://darkcointalk.org/threads/development-updates-july-7th.1735/

The DarkSend+ anonymity depends on MasterNode1 and 2 are not Sybil attacked in order to achieve unlinkability and untraceability, and adds some of the blockchain bloat of Cryptonote. Cryptonote (Monero) achieves that without any such Sybil attack threat.

Both Monero and DarkSend+ share the Sybil attack threats:

1. On mixing transactions thus incentivizing transaction spam. This is the other major flaw of Cryptonote and CoinJoin which forces transaction fees! Mining share payments for transactions as tromp suggested will not curtail spam because a mining share is profitable to generate, and can only contain the total level of transactions by raising the share difficulty required high enough to lock out those who don't have enough hashrate (which makes the Sybil attack on transactions worse assuming the adversary has a higher hashrate some user).

2. On the I2P/Tor network used to obfuscate the IP address of the spender.


https://darkcointalk.org/threads/development-updates-july-15th.1788/

Continuous mixing won't scale, because it explodes the transactions by some square lawextra factor. So if you think the scaling calculations I showed for Monero were egregious when scaled to Visa scale, get out your calculator and run them on this DarkSend premix idea.  Shocked

It is comical to watch them tack on multiple layers of duct tape on a fundamentally flawed algorithm.
legendary
Activity: 2968
Merit: 1198
July 28, 2014, 08:36:18 AM
smooth, I realized we were discussing an irrelevant tangent, because regardless of the fact that by default I2P makes clients relay nodes (at some percentage of direct connection success) and Tor doesn't, the ability to Sybil attack these networks is only dependent on total network bandwidth. Since Tor is more popular (is it?), it is more difficult to Sybil attack.

I don't really know which is more popular, nor if that correlates with bandwidth. Tor certainly gets more press but I2P is supposedly widely used for file sharing, which is pretty bandwidth intensive.

Perhaps someone else is more familiar with the usage and scope of I2P. I've never tried it.

Jump to: