Topic: rpietila Altcoin Observer - page 132. (Read 387551 times)

There are no dedicated relay nodes in i2p the way there are in Tor. I2p relies on a bit of social engineering for relay nodes, which is that relaying is turned on by default. So if you are using i2p, you are a relay node by default, and it can reasonably be assumed that most never change defaults. Even if a few do, the rest provide a large relay network sort of for free, but sort of in exchange for the benefit they receive by using the system.

I think Anonymint is a little too demanding or perfectionist in terms of coin/protocol specifications, such as zero transaction fees, but here's my current reasons for why I can't really support Bitcoin or Monero, which is a Bitcoin derivative:

Cross posted from:  The BTC price is too high for it's current security model

https://bitcointalksearch.org/topic/the-btc-price-is-too-high-for-its-current-security-model-710107

If mining is centralized then the exit points are probably easy to find.


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 not read the research on traffic analysis to comment with complete confidence. My technical understanding is likely close.

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. This is a statistical analysis. If it can be seen over time that a targeted entry node is always correlating with low-latency to one of the Monero exit nodes (made more easy to find by centralization of mining), then it is mathematically provable (within statistical confidence) that those packets are coming from the entry node. Thus IP obfuscation and anonymity broken.

The obvious solution of using a different entry node for each transaction sent, means you need to source many unregistered internet connections. Well then you might as well just use one unregistered internet connection then you don't need I2P/Tor and you can use Bitcoin or any coin.

And no improvements to onion routing (Chaum mix-nets) are reliable if the relay nodes are Sybil attacked, and many people assume they are because who is providing all this relay traffic for free. For example if 20% of the relay nodes are the adversary, then with 3 onion layer hops you have ≈1% (0.2^3=0.008) chance of being non-anonymous across the 3 hops each time you connect to the network. So over 100s of transactions your anonymity will be defeated. Worse yet, the research shows that the higher the % of the nodes the adversary can monitor (either by owning the node or by watching the routing of traffic across the node), then the frequency and/or randomization of latency of the cover traffic has to increase. Worse yet, even if you say your odds are low enough for your choice, when you lose anonymity then others in the ring signature lose anonymity too, i.e. your lower threshold choice cascades to others that wanted a higher threshold.

Thus you see low-latency Chaum mix-nets (onion routing) are a fundamentally flawed concept for anonymity against a global adversary. Even a hacker has access to a botnet might be able to Sybil attack the relay nodes.

On the order-of-magnitude of 20 txs/sec per core on a late model CPU, i.e. an order-of-magnitude higher than Bitcoin (<1 tx/s) now per core but two orders-of-magnitude less than Visa (2 - 6K tx/s) now per core, means Monero (Cryptonote) can't scale to any where even close to global Visa scale and remain both decentralized for mining with fast block period (thus fast transactions), not to mention the likely order(s)-of-magnitude more scaling above that to reach ubiquitous global micro transactions and programmable contracts on the block chain.

So you would have to solve both this and the blockchain bloat in order to scale to global widespread use. It appears that one-time ring signatures are fundamentally incompatible with scaling.

Cryptonote can't encourage too much use with zero transaction fees, because it can't accept the scaling that can come with it.

I believe Zerocash has similar scaling issues. DarkCoin (and CoinJoin) has the simultaneity problem that fights scaling because to mix you need someone else who wants to mix with you at the same denominations at the same time (not mention being either theoretically defeated with jamming and/or Sybil attack on masternodes) and to perform this meeting with scaling you need global coherence on submitted txs which means either centralization (synchronicity) or no scaling.

This is total rubbish, almost every scamcoin now has a roadmap where they solve all the problems described in a white paper.

Good luck with that, I have lost hundreds of Bitcoins to scams, and can tell a scam apart now, I see you have yet to learn this.

Good luck with their 2.0 version of their currency, perhaps they should have solved these issues before releasing?

I believe Tor and I2P should not be conflated. Timing attacks are more difficult against I2P. With Tor, you have exit nodes which make it easy to see one of the endpoints for the purpose of correlation. It can still be done without visible exits, but this is a bit harder.

There has been some talk about introducing random delays to harden the mix network layer. Since that has various drawbacks, how about adding cover traffic instead? It is wasteful but should still allow low enough latencies while mitigating timing analysis. This is another thing that would not work well with an exit node based system.

Apparently we have a new market leader and anon king in town, CLOAK:




According to the whitepaper it has ideal solution; peer-to-peer in nature, decentralized and trustless.

Since you asked, I just looked in the log file on a 4-year old Xeon server I'm using as a node. It takes approximately 0.14 seconds from the time a new transaction arrives until the time it is relayed. I believe most if not all of this processing is single threaded, which suggests approximately 7 transactions per second per core on a 4-year old CPU.

If you emphasis on reading comprehension, the actual questions was how many processor cores is need to verify the incoming transactions + the mined block? Let's suppose you have a short burst of up to 5 transactions a second, is it one core? Or two, or eight? Have you actually bothered to measure?

Again, reading comprehension is important. The question was about scaling to the current rate of Bitcoin transactions, which is to say something that a comparable system has been demonstrated to be able to handle, thus a realistic basis for comparison. Scaling Visa rates or anything close to that has not been demonstrated by any comparable system.

tromp, did your Cuckoo hash remain sublinear parallelizable at 32 cores or did it fall off faster?

In the presence of perpetual debasement, transaction fees could be optionally replaced by proof-of-work
where difficulty threshold is some function of the transaction amount (this function could be dynamically varied
based on recent block fill rates).

One would hope that 60k transactions a day is not the apex.

Bitcoin runs about 60K transactions per day which is less than one transaction per second. Even allowing for the fact that transaction flow is not constant throughout the day this is not even close to being a serious issue.

This isn't just a concern of disk space, which can be remedied with adding more disks in RAID, people keep forgetting individual nodes have to verify all those scripts in that data in order to individually verify the blocks. It essentially boils down to more centralized mining, and being very prohibitive for smaller development projects to be self sustained and not depend on the third party to trust. I would be very glad to see the projection from the Monero developers how many processor cores would be required for full Monero node to run with amount of transactions getting close to Bitcoins.

Zero transaction fees combined with a flexible blockchain structure that can support, e.g., arbitrary user data or extensibility are a recipe for letting people externalize their costs.

When you're consuming storage in a medium replicated 1000s of times around the world, paying a little rent is a good idea.  Otherwise, some clever schmuck will figure out how to store a copy of windows ME in the blockchain, and we'll never be rid of it.

So if Monero goes light or zero on transaction fees paid with perpetual coin rewards, then the blockchain can be spammed to more bloated.

Only the mini blockchain can scale well with the increased transactions and usership from zero transaction fees, and that is if you can stop spam. And even then you need to get rid of dust.

Interplay of design of a coin is holistic.

Agreed - in my opinion it's the most elegant solution, as it prevents miner collusion and selfish miners artificially forcing a fee increase by rejecting / slowing down min-fee transactions. Fees may still serve a dual purpose, though - both as a way of preventing spam, and as a way of indicating transaction priority.

Obviously you'll get significant resistance from shortsighted individuals, but long term, I don't think there's any other solution (perhaps heavy transaction fees). At least not yet.

Monero is going that direction as well, though there is healthy debate about the exact amount and structure. We don't however believe (as bitcoin does) that transaction fees alone supporting miners is a good approach.

I don't agree with zero transaction fees for the most part, but I'm not sure.