It got really quiet in this thread. Did I say something sufficiently offensive, shocking, or motivational?  Here's a genuine Altcon Observation to discuss: XCN successfully moved to pruned mode, and its price spiked up ~27% from the deep support at 0.00001375. XCN cracks two hard nuts at once. Mini-blockchain is ultimate prunability (so a full node may run on your phone). And withdrawal limits on the account tree enable non-malleable zero-confirmation transactions. Like E=MC^2, scarcely two dozen people in the world grasp the magnitude of this technology's implications.  The shilling must end. This is worse than the HashFast thread, where you enticed people into losing millions of dollars.  |
|
|
|
While I like the concept that Cryptonote is based upon, I'm thinking that Darksend+ (RC4) should be better. We shall soon see this.
CryptoNote is based on the application of passive cryptography to secure privacy, while DarkSend+ is based on onion routing of transactions. Based on the history of onion routing security breaches, I'm not (and have never been) very enthusiastic about DarkCoin's model. Ring signatures, Diffie-Hellman key exchange, and small non-interactive zero knowledge proofs have a long established history in cryptography, and I feel safer with their usage. |
|
|
|
Rogue miner seems like a very broad brush. Why would a rogue miner bother to mine such an unprofitable coin? Even if their costs are zero, they would be making more money mining XMR or other coins for that matter.
I don't believe it's a botnet, I suppose it could be a buyer looking to accumulate qty as cheaply as possible, but they would presumably understand there becomes a point where the price drops so low- catching a continuously falling knife seems like a losing proposition, miners have more profitable ventures to chase, buyers become disheartened totally- the coin can be seen as dead in the market and very tricky to revive at that point. Don't think any rational person interested in increasing BBR holdings would be making such a move in that case. I wouldn't beleive it's few entities looking to exit totally either, anyone (especially someone with quantity to sell) can see the buy support is paltry and would definitely be better served selling off-market than dragging the price down gradually. Could jealous older brother who has always disliked younger brother BBR and wants to switch life support off,be with younger bro out the way spotlight is fully on them, It does not take much to kill the coin at this rate. An interesting experiment would be to wipe the orderbooks out to 0.0000x range and see what happens. We already are @ -3550% XMR market cap, despite this being the stronger coin in a number of ways. It shouldn't be such an uphill battle but it will be. LOL, why would BBR be a threat? especially when there are other, self proclaimed anonymous coins, that have a much higher valuation than BBR. I am sorry, it doesn't make any sense. You can see smooth posted earlier in this thread although not sure why he wanted Christian to keep the miner private. IMO he should have discouraged it. But he follows the coin I am guessing. tacotime also has a BBR alias registered in his name. I also know at least a few other XMR holders who also like BBR. Yes they don't exclusively "push" BBR, but can you blame them? It is economics after all. I am sorry this is a wild theory. But as I typed this, I can see where you are coming from. Sorry if I sounded more dismissive. I have no idea whose alias that is, but it's not mine. |
|
|
|
I know this is intended to eliminate the need to load the blockchain into ram but will it do anything to address the size of the blockchain? either the size that it is now or the rate at which it is growing.
Potentially the on-disk size may be reduced (both initial size and growth rate), but we don't know how much yet (and probably not in the initial release). The original upstream implementation is as much as 2-2.5x larger than it needs to be. Well, that's partially true, but I think we do need two databases, one for blocks themselves (keyed to header hash) and one for transactions (keyed to txid). The one for transactions can hopefully eventually be replaced by one for utxos that has most of the tx themselves pruned. But for now I'd guess the databases will store information like this, for rapid verification of payments. |
|
|
|
Nutshell on how database is coming?
Tewinget hasn't pushed commits on it lately, he's been moving and so hasn't been around much. He'll be back soon. It's a major architectural overhaul, so it'll be a little. |
|
|
|
Is there some group dedicated on developing monero-based services? Is there a development team working to make Monero significant?
There are a lot of people who want to make services. Developers I talk to about how to do them. However, so far, I've warned a lot of people against the creation of services until we've implemented proper privacy services and the database. We're making good headway into statistical analysis of the privacy features now and will roll out fixes soon. |
|
|
|
PoS is a totally different animal, and getting someone who has been a strong believer in PoW to review PoS objectively is a problem  because in case they find out PoS is safe and better, they can't back out of this, because then math would prove it, which means the status quo of their PoW investments would be shaken. So for now the approach is to stick the head into the sand hoping PoS would just go away by itself As a Proof-of-Stake systems developer for the past year and a half, my personal opinion is that all of the PoS systems are different levels of insecure (I have doubts that even the one I'm designing is secure, but I'd like to see what happens). |
|
|
|
any new features or insights that you want to incorporate into mc2 now after gaining exp with monero ?
Sorry for the long reply, didn't see this until now. I probably won't be considering ring signatures for now (it's a lot of work), but may switch to EdDSA for the signature scheme. I don't think I'll be initially added stealth addressing either (but you can always do it yourself with OP_RETURN pushes). |
|
|
|
So mining isn't anonymous?  No, we aren't concerned about miners. 90% of blocks are mined by public pools anyway, there's no real point. We're mostly concerned about the people using it for barter transactions. |
|
|
|
Othe, according to things that smooth said about problems with nodes bandwidth overhead, this i2p implementation looks really strange, since it definitely make this also slower.
I have no doubts that you informed about all issues and would be happy to see a result when you finish that.
The I2P network is designed for interaction of persons making transactions with main nodes without revealing your IP. It's not intended for general use (we will continue to use the normal P2P code for that). |
|
|
|
Centralization is the near-term enemy. Bitcoin is already there. Monero has not innovated at all on decentralization of mining. There hasn't really been any decent alternatives. For any proof-of-resource chain, it will tend towards centralization. That centralization can be concentrations of stake or coinage, or signing delegates, or hard drive space, or bandwidth, or whatever. A censorship free, decentralized, provably temporally stable messaging system for which we can transmit and then store transactions simply doesn't exist. I have a lot of doubts about whether or not there will be a solution to that. I think it will be proven impossible before it will be proven possible. |
|
|
|
This is a very reassuring thing to read. Particularly this "mandatory participation in anonymity sets" i am very strongly in favor of. What sort of mixin minimums are you guys thinking of at this time? it seems like a mixin count of 2 or greater would probably get the job done well enough and be a good trade off where as mixin 1 is probably too low.
We're trying to model deanonymizing attack vectors on the network right now with some math grads, but at least mixin >= 1. |
|
|
|
For the time being I am looking at solving the diff issue.
Is this your chain?
I'm one of the core team members and the original person to fork the bitmonero repo, so I have some say in what gets committed to master. |
|
|
|
This is a scary thing to read. The jack of all trades will always be the master of none. Any one who makes transparent transactions reduces the anonymity of all other participants or forces them to pay a higher cost to regain the same level of protection. It imposes externalities on other actors. Anyone who wants transparent transactions can just go use bitcoin, there is no need to have a single network that does both when we have 2 networks, where each does one of the two. I hope this sentiment is not echoed by too many on the dev team. Actually, that's an interesting bigger-picture question. Is the network stronger if an anonymous technology is used for all transactions, where a fraction of them are deliberately made transparent; or is the network stronger if BTC is used for transparent transactions and XMR/BBR/foo is used only for anonymous transactions? My concern about the latter is guilt-by-association. We know, for example, that the NSA archives permanently all encrypted data, but (publicly says) that it does not retain certain classes of unencrypted data. One or two anonymous transactions per minute may be much more easily traced via traffic analysis than 1000 anonymous transactions per minute mixed together with 10 deanonymized transactions. This is based, admittedly, on the assumption that people who don't carefully ask the question of whether they want anonymity will default to BTC. We're working now to add better privacy features, like mandatory participation in anonymity sets, a proper I2P protocol for transaction submission to network nodes, and more elaborate methods of transferring funds that obfuscate transaction submission time to the network and transaction destinations. Of course, if the NSA is sitting sniffing your personal packets off your network, there may not be a lot to help you at the current time. Other persons are working on some censorship free networks for the near future, and there are becoming better ways to enter the internet using physical cash. Privacy online is a difficult thing to achieve. |
|
|
|
Hacking away. Simulation network is functional on some basic features. There'll be a testnet in the coming months. |
|
|
|
* The blockchain will be (and grow) most likely larger than bitcoin one (for the same usage), by a linear factor. Probably something like 5~20 times. Many people don't think it's a problem since it's the price to pay for anonymity. Is this range of numbers not acceptable for you?
If MRO has a goal of being confined to a niche coin used only by people that have an absolute need for anonymity, then a huge block chain that crawls is no issue. If MRO desires to be a widely accepted form of money transfer and storage, then speed and anonymity will be what puts it out front of all coins. No such coin exist today. Solve the diff issue, solve the bloat issue, break the known barriers.~BCX~ The diff issue we're not too worried about. The current algo requires you to manipulate timestamps for 12 hours, which is difficult, and you'd need >50% hash rate to successfully pull off a timestamping attack given that you can't overtake the main chain without a higher cumulative difficulty. If you have >50% hash rate, you can do lots of other terrible things anyway. As far as the bloat issue, we watch the blockchain every day to make sure it isn't being abused, if it is we'll raise fees immediately and pass that code to the pool ops. We're trying to keep the fees low to incentivize the spreading of wealth around right now. I wouldn't really classify Monero as a shitcoin, we never had a premine or instamine (like ByteCoin) and the distribution so far has been very fair: http://monerochain.info/charts/coins |
|
|
|
We did already, but I didn't like the way that was implemented (it looks like it spins up internal testnets more akin to regression testing). I already wrote up some specifications for a Bitcoin-style testnet, so we have something operational for lots of people to play with along the lines of bitcoin testnet3. In the testing suite there already is something very similar to a regression test anyway, that just needs to be fixed. |
|
|
|
The test in this is whether the Monero team addresses it in an adult way: Will they add tests and/or procedures to *prevent this same kind of error* from getting introduced again? Will they communicate that they've done so?
We are trying to. We don't even have a proper testnet functioning, which makes things difficult. I added a note to the repo in issues a while ago for the addition of a testnet and the fixing of the test cases from the original ByteCoin code (most of which are now broken). It's difficult. I code full time on another project, we only have a few dedicated, paid f/t devs at this point, and we're constantly trying to implement new things that have been requested by exchanges and others. I'm around to talk to if people want to hack on the project and have been working with the f/t devs to try to get out majorly needed features like an actual database, and I've been emphasizing fixing the testing suite for a while now. |
|
|
|
So, basically you wasted users money because of your incompetence?
Wasn't my code or my merge; when devs commit things to HEAD we warn everyone that they're experimental. |
|
|
|
|
Show Posts
