http://chainradar.com/bcn/blockshttp://chainradar.com/bbr/blockshttp://chainradar.com/xmr/blockscan anybody comment on those three pages and what it indicates?
I have always been focused on usage, not speculative prices. With cryptonotes, the blockchain size is a key issue and while BBR has the pruning, if it has to be RAM resident that defeats the purpose to a large degree. I am very glad to see a DB version in testing as until that is out, the footprint is too big.
In the last year I have coded from scratch ramchains, MGW, InstantDEX, SuperNET agents, atomic wallet swaps, jumblr coinshuffle, pangea decentralized poker and PAX pegged asset exchange, currently ~100,000 lines of C code. This is just the code I personally wrote, not counting all the non-coding issues of managing a large decentralized community, nor of the contributions of dozens of other devs. I dont believe many people understand the full scale and scope of what I am working on, let alone of the entire SuperNET.
Due to my workload, I am not posting much on BTT, nor can I be proactively working on BBR integration into SuperNET at this point. That being said, I think what can be done is for a SuperNET agent to be created that allows for using BBR by all the SuperNET nodes. A SuperNET agent allows a set of node(s) to publish a service to all the other nodes in the network, this is how MGW is implemented. I think combining coinshuffle with a cryptonote would be quite a powerful combination.
A BBR agent would facilitate its usage, but really what is needed is more active involvement by BBR dev team in the SuperNET slack. If you think of SuperNET as a shopping mall, then the BBR store is there, but without BBR peoples, it will be an empty store.
James
James,
Thank you for your response. What is your specific question about the chainradar data? For each block it lists the timestamp, block size, number of transacations and hash. Difficult and emissions totals are there too. What are you wondering?
We are excited about the DB version too! I am glad to hear that it will also help with SuperNET.
I can pass along your comments about wishing more people were in SuperNET slack. We know you have been very busy over the last year. Can I ask why you decided it best to combine coinshuffle with CryptoNote instead of using CryptoNote alone?
I will cross post this to our announcement thread as well for more visibility.
look at the transaction volumes, even for BCN which is almost 10x the volumes of XMR and BBR has more transactions than XMR.
Now cryptonote tech is all fine, but let us imagine you are using a payphone in the australian outback and you are the only one that used a payphone that hour. just exactly how much privacy can cryptonote, or anything provide, when the transactions are ~10 per hour?
subtract out the mining tx and we have hardly any transactions. So if anybody seriously believes that even all the cryptonotes combined can provide privacy for 100 BTC of value over a small period of time, they are deluded. At current volumes, maybe over a month it will take, maybe more, havent done the calcs.
The jumblr coinshuffle i did works with BTC, LTC, BTCD, basically any bitcoin compatible, so it taps into the vast transaction pool. Now imagine being able to combine the privacy of cryptonote, with a realtime coinshuffle (no blockchain record of the shuffle), with the large transactions of BTC. In my opinion, only such a combined approach will provide any real privacy.
However, even that is not enough!
If there is a background level of 10 tx per hour, then it is a trivial matter to correlate any large spike. Depending on the resources the attacker has, even the IP address could be correlated if protective measures are not taken. If everything is on the blockchain,then down the road when QC computing is available, then the entire history becomes an open book. That is why offchain shuffling is a critical part of the solution.
Another critical part is simply having a lot of activity, say something like a blockchain enforced decentralized poker.
BTCD will have a unique method of delinking transactions where the initial recipient is very nearly 100% protected, even at the IP level. However, the initial sender is still linkable to the second recipient:
Alice -> Bob -> Charlie looks as Alice -> Charlie, with Bob nowhere visible on the blockchain, ever.
the coinshuffle makes the "->" a bit fuzzier, but this is an area where the more volumes, the better for all, especially if the "->" is using cryptonote as input and/or output. but once we do cross-currency shuffles/transfers, then it exposes the exchange between the two as a possible attack vector.
As you can see, to solve privacy for real not just on paper, it is a very difficult and large task. Without volumes, there is no privacy, that is why I am frontloading things that will create the volumes. What point to have perfect privacy on paper that in reality is trivial to brute force correlate due to small overall volumes?
James
Thank you for all the thought you put into this. I think I understand your concerns. I have some ideas about the transaction data as it relates to privacy but will not make any comments on that quite yet. I think there are some people at Monero Research Labs who have thought about this and have some suggestions. Thanks again for your time. Hopefully some BBR people will get more active in slack soon.
