Topic: CryptoNote technical discussion and Chess Challenge - page 38. (Read 96147 times)

Question for languagehasmeaning, if he is willing to answer. Or anyone who can offer an insight for me.

I am curious. How many moves ahead can you calculate all the possibilities? And is that even a useful computation in playing the game, or is the useful computation probabilistic? Apologies I am ignorant and I am curious about from someone of your caliber, what you can actually do mentally that enables you to win. I suppose I could learn this from books and I haven't researched it.

36. Kf2

36.Kf2

At first glance it appears forced. There are no other good alternatives to prevent both Nxg3 and Ne3

Current position
Based on the votes in this thread Team Boolberry has chosen to play Nf5. Now it is time for Team Monero to respond. I will plan to count votes again tomorrow at approximately 0:00 UTC.

Team Monero (white pieces) vs. Team Boolberry (black pieces)
white to move


Game PGN:

20 more minutes until the current vote is final.

Check this game out. It just got really interesting IMHO. Should team bitcoin accept the exchange sacrifice? We chose the Marshall Attack so that we could be the the aggressor but the last move of letsplayagame 18.a4 caught me (and probably others) by surprise:

https://bitcointalksearch.org/topic/lets-play-a-game-of-chess-1148538

On the Cryptonote technical discussion and my recent thoughts about anonymity:

1 vote Re8 (languagehasmeaning)
3 votes Nf5 (galdur, newb4now, boolberry)

He doesn't think that I2P and Tor are NSA-proof. That's hardly an outlier point of view.

What is wrong with the planned solution of I2P integration to deal with this issue?

1 vote Re8 (languagehasmeaning)
2 votes Nf5 (galdur, newb4now)

I like tricks in chess games!

Thank you. Nothing wrong with Re8 that I see but I´ll try Nf5. There could be some tricks if white plays f4 and the g-file opens.

1 vote Re8 (languagehasmeaning)
1 vote Nf5 (galdur)

Welcome to the game my friend. I agree it is getting more interesting but also agree with galdur that a draw is most likely if both sides avoid major mistakes.  There definitely are still some tricks in the position.

Re8

It indirectly defends e2 for our knight (and therefore indirectly defends f4). I prefer Re8 over Re7 because if the g file opens later our c7 rook can move there while our b8 rook cannot (g8 is covered by whites bishop). Our most passive piece is currently our rook on b8.

1 vote Re8 (languagehasmeaning)

Current position
Based on the votes in this thread Team Monero has chosen to play Rf1. Now it is time for Team Boolberry to respond. I will plan to count votes again tomorrow at approximately 0:00 UTC.

Team Monero (white pieces) vs. Team Boolberry (black pieces)
black to move


Game PGN:

Zerocash does hide your identity on the block chain even if your IP address is correlated across multiple transactions that you send to the block chain, because in Zerocash the payer(s) and payee(s) are obscured and proven in a non-interactive zero knowledge proof (NIZKP). This is accomplished by proving that the machine ran a certain program (and no other program) on the inputs and that result was "true" (i.e. verified), rather than proving something algebraically about the variables to the program. This computational witness requires the global master key setup.

Whereas, Cryptonote one-time rings mix the payer amongst a group of payers with the requirement that it is publicly verifiable that each payer can only be spent one-time. The one-time key is manufactured by the Diffie-Hellman (ECDH) like exchange that creates a new stealth payee address on each spend and that stealth address can only be spent once. So the problem is that if your IP address is correlated across spends, it becomes possible to link stealth addresses together as the same payee and then start to unmask the anonymity set of the payer rings.

So it would seem that Zerocash is the solution, except read my discussion at the quoted link about anti-DDoS protection. The problem is the huge verification cost for each Zerocash transaction and thus giving the attacker a huge asymmetric advantage when sending invalid transactions, i.e. unprotected Zerocash can be DDoS'ed to death.

And if using my suggested technique to create a hash-based signature as a first line of verification of incoming transactions sent to the block chain, then you've got to incorporate a simultaneity mixnet such as CoinShuffle to detach these hash signatures (and the payee's IP address) from the Zerocash transaction being submitted to the block chain. But then your anonymity is reduced back to the mixnet again so you've lost the benefits Zerocash provides. Perhaps Zerocash could devise a quick check on invalid signatures. I don't enough about the "moon math" in the white paper to deduce whether that is possible, but I 95% doubt it based on my understanding that such NIZKPs are a holistic math affair.

Perhaps instead of my hash suggestion (and as suggested by Gregory Maxwell at the aforementioned linked thread), each Zerocash (or RingCT) could require some PoW be attached to every transaction to rate limit spam, but the problem is the attacker has an asymmetric advantage by being able to place his hashing resources in venues with the cheapest electricity (e.g. 3 - 4 cents per kWh in WA State or China near hydropower) and leverage the latest ASIC efficiencies whereas the legitimate payer is running on retail electricity that costs 4 times more and non-optimum hardware that is at at least an order-of-magnitude disadvantage in power and speed. So the delay (or the transaction fees if the full nodes speed more on hardware to increase their spam bandwidth) will increase for legitimate payers asymmetrically to the attacker's costs. And that asymmetry will be amplified by the systemic ratio of the resources of the legitimate payers to the attacker's resources, thus if the anonymous system is only used infrequently then the cost of using it will be radically amplified (perhaps too high to be of practical use, although I haven't done some sample calculations yet). And for the system to be widely used (e.g. for microtransactions) the extra costs imposed by the attacker disincentivize its use when the legitimate participants don't value anonymity as a concern. Also the PoW required could vary per full node and vary in time (even in real time!) depending which nodes are receiving the most incoming DDoS spam, which complicates the determination where to submit a transaction and how much PoW is required to be submitted with it. So then it appears any any such Zerocash + PoW anti-DDoS system is going to be used only for anonymous mixing and not all transactions, but then the problem is the anonymity leaks as these anonymous mixes are then traded for coins in a system that is used in everyday commerce (e.g. microtransactions).

Even though I haven't thoroughly understood every technical aspect of it, the other problem with Zerocash appears to be that it can't merge the entirely opaque block chains, e.g. if there are two major chains fork due to a network split. Transparent block chains can be re-merged to the extent that double-spends are not intertwined. The major fault for Zerocash (that is not present for transparent block chains) being that I believe it is not possible to prove which coins were double-spent on both of the block chains. Normally this isn't a problem for an orphaned chain because you just throw away the orphans, but this is perhaps a problem in a major network split.

It seems very even. The bishop is maybe slightly better than the knight but I doubt that it´s meaningful. I´d say a draw is practically certain.

This game of chess finally got interesting!   

Not necessarily, no, but the technology will still be important.


The real world doesn't work that way. Business collaborate one day and compete the next (or even the very same day). Even when collaborating they don't want to share all information, and certainly not with every member of a group. To control access to information once access to the blockchain has been granted at all, privacy features are needed.

Permissioned blockchains will often need privacy, just as the current example (or maybe more near future, but I'm not sure of the deployment schedule) of the Liquid permissioned blockchain does. Depending on the nature of the use cases for the permissioned blockchains, there may be some exceptions (explicitly public records perhaps).

Furthermore, I'm not even sure there will be too many successful permissioned blockchains. In the past, there were many proprietary closed networks. A few still exist, but most communication now happens over the regular internet. Not even VPNs, but web services with access keys. The need for many interconnections may in time make these closed/semiclosed systems impractical and/or cost-ineffective even when the interaction takes the form of blockchains.

So, are you out of Bytecoin now (i.e. own none), Rias? Just curious.
Cheers, Q