is mymonero get affected by this fork?
Yes, busy fixing some issues that slipped past |
|
|
|
Crypto-pool.fr got booted off for the first 12 blocks or so, but they are finding blocks again now.
He didn't get booted off, the fork was NOT COMPATIBLE with pool software. Onishin is a smart guy, i'm not surprised he fixed it in to time (still took him longer than me  ) No, the pool software was not updated to support a well publicised fork, even though testnet was forked months ago and available for testing. Why and how would a hard fork support outdated software?? |
|
|
|
It doesn't matter. The real answer is simple: the storage layer s (plural!) need to be abstracted. No single engine could meet all needs. That's precisely what we did with Monero. We abstracted our blockchain access subsystem out into a generic blockchainDB class, and then build out implementations for LMDB (default, preferred) and for BerkeleyDB (failover). Of course, there exists a risk that a portion of the network may be forked off if in an edge-case between implementations, but that's no different to a subset being forked off the network because they're running 32-bit whatever in a 64-bit world. |
|
|
|
I think credit must be given where credit is due - it's good that they've built out Tor and I2P versions of Electrum. I think it's pretty short-sighted that they haven't engaged with the Electrum dev community to add I2P support to Electrum server, which would allow Electrum volunteers who are already running servers on Tor and/or clearnet to add I2P support to their server if they so desire. I also think that it's largely irrelevant whether the Electrum server knows your IP or not, you're already providing it with so much metadata that grouping your addresses becomes trivial. Who cares if you only ever use Electrum over I2P, but then you go buy a yoyo online and an attacker gets your physical address from that payment (and they can link every transaction you've ever done)? Another concern that I have is with I2P's router being written in Java. It's not terrible, but the additional dependency (especially one with such a poor track record) is a little frightening. It's also the primary reason why we've been working with members of the I2P community to get C++-based I2P router projects going, which will allow much better and more direct integration. Hopefully Verge will switch to Kovri when we're at a stable and secure release point: https://github.com/monero-project/kovriThanks for the detailed input, I agree that an I2P version of Electrum is a nice feature. I have no problems with their developments and didn't have any in the past. The attitude bothers me. Saw your I2P router project previously, how is it progressing? Good - we're uncovering lots of stuff-the-spec-says-but-the-implementation-does-differently issues, and it is a COMPLETE pain to secure it, but I think there's a lot of good stuff coming out. For instance, I2P's reseeding is almost entirely centralised - they have a central maintainer (as in a person) who actively maintains reseed lists!! They're basically unaware of all the stuff that Bitcoin has done on the seeding side, not through ignorance, but because change is hard. Similarly, they have tons of RNG fallback stuff, but in 2016 the prevailing advice is " use /dev/urandom or CryptGenRandom()". This wasn't true back-in-the-day, but the implementation no longer reflects the environment. |
|
|
|
I support it, and the rate seems pretty reasonable. Of course, in my head, Monero is still worth 50 cents.  So you're saying that Fiddy Cent loves Monero? |
|
|
|
I think credit must be given where credit is due - it's good that they've built out Tor and I2P versions of Electrum. I think it's pretty short-sighted that they haven't engaged with the Electrum dev community to add I2P support to Electrum server, which would allow Electrum volunteers who are already running servers on Tor and/or clearnet to add I2P support to their server if they so desire. I also think that it's largely irrelevant whether the Electrum server knows your IP or not, you're already providing it with so much metadata that grouping your addresses becomes trivial. Who cares if you only ever use Electrum over I2P, but then you go buy a yoyo online and an attacker gets your physical address from that payment (and they can link every transaction you've ever done)? Another concern that I have is with I2P's router being written in Java. It's not terrible, but the additional dependency (especially one with such a poor track record) is a little frightening. It's also the primary reason why we've been working with members of the I2P community to get C++-based I2P router projects going, which will allow much better and more direct integration. Hopefully Verge will switch to Kovri when we're at a stable and secure release point: https://github.com/monero-project/kovri |
|
|
|
Well it would be nice if the team or somebody else can develop an user friendly 1 click wallet right? Would also gain more people and attention...
There is also a simple web wallet I see, is it safe option as well?
It's from fluffypony, who is a core-team member, thus considered safe as in trustworthy. However, one should always be cautious with using webwallets. More specifically there have been successful thefts. Fluffypony explicitly recommends not storing too large an amount there, and instead using it for convenient access to smaller amounts. Is there a thread or such detailing that? This one for example: https://www.reddit.com/r/Monero/comments/491gbj/i_lost_some_monero_that_i_had_on_mymonerocom/d0ocdpmBut like fluffypony explains in the comments, it is not the webwallet itself but all the (potentially weak) links between (and including) the users computer and the server (the ISP, the VPN provider, TOR exit nodes, CloudFlare, etc). So only use it for pocket change, like your 'real' wallet. +992983741982371023 I'm in the process of making that a little more clear on the wallet creation page, since I fear for people using it as a form of cold storage. Every time they login they risk their funds getting swiped:/ |
|
|
|
is monero ever going to catch up to eth, eth seems to always be like a rocket ship while xmr is making relatively slow gains.  Thank goodness - can you imagine if Monero was backed by a 19 year old kid and his corporate board of directors? I wish them all the best on future decision making, will be sad to watch the community disillusionment as they realise how unimportant the community is to Ethereum. But don't worry - they'll pivot and put community voting in the blockchain with some complicated voting system that is broken in so many ways, and everyone will just accept it because said kid is a "genius among geniuses" and everyone daren't argue with that! |
|
|
|
|
1500 pages! Not bad, chaps.
I must say, I'm really proud that the community and this thread has generally stayed focused on the technology, and "price talk" has shunted over to the XMR Speculation thread. Makes for much easier reading:)
|
|
|
|
The concept of "colored coins" makes me think of coining the term "CRYPTO RACISM"....
"Don't hate me because I'm black!"
Monero does not crypto-racially discriminate. <----- could be a slogan for Monero lol
You're still my crypto, it don't matter if you're black or white  |
|
|
|
Well then thank goodness Monero is so much more than a one trick ... err ... pony. Also: PoS, lolzworthy at best. Just like you! No wonder you like it:) |
|
|
|
EDIT: too slow. You dEBRUYNE and fluffypony are amazing, thanks for the effortless support.
Given how rarely I comment here that is a compliment of the highest order...thank you, although dEBRUYNE definitely deserves the majority of your gratitude:) |
|
|
|
Agreed - none of those transactions have payment IDs. |
|
|
|
Just checked. South African Rands take up no disk space and don't eat any RAM. Best of all, they're exceptionally private.
GUYS LET'S ALL SWITCH TO SOUTH AFRICAN RANDS, K TKS.
Wow. What's with the caps and the yelling? Are you the face of the project? No. I am the scapula of the project, though, so there's that. |
|
|
|
Will better database compression be integrated into the client?
I just compressed the databse with 7-Zip and it has decreased from 7.9GB to 4.2.
The database is denormalised for performance currently. We will normalise the tables over time, depending on how it affects performance. We discussed a database format migration mechanism at the dev meeting on Sunday, logs are here: https://getmonero.org/2016/02/14/overview-and-logs-for-the-dev-meeting-held-on-2016-02-14.html |
|
|
|
Just checked. The Dash Electrum wallet takes around 80MB HDD space and eats 29MB of RAM.
Just checked. South African Rands take up no disk space and don't eat any RAM. Best of all, they're exceptionally private. GUYS LET'S ALL SWITCH TO SOUTH AFRICAN RANDS, K TKS. |
|
|
|
Well I do and Crawallmining does also.
Who? |
|
|
|
Congrats to that guy for de-anon'ing the whole SDC chain - thats some pretty major pwnage. In fact it was so impressively devastating Im slightly worried about the same fate befalling XMR. These things always require a small leap of faith, however, and you guys might be bright enough to pull it off…
All cryptography requires a leap of faith. The thing that protects Monero's transactions from being deanonymised is the invocation of a secure hash function to create the key image. As has already been extensively written on, Monero uses a secure hash function for this. A break in a secure hash function has much wider consequences than deanonymising Monero - there would be a significant amount of brokenness in other systems. Trusting Monero's privacy is a matter of trusting hash functions, cryptographic signatures, elliptic curve cryptography, and your system's PRNG (pseudorandom number generator). Since you're already trusting all those things to use Bitcoin and not have your funds stolen by a cryptographically breaking attack, you should be able to trust Monero in the same way. |
|
|
|
|
Show Posts
