[...] Monero is most fundamental coin to the day. Not only it is strictly anonymous, it has double-spend proof even in case 51% attack. [...]
That's new to me. Is this true? How is that supposed to work? Man you know this coin has got to be good. Just read the whitepaper! Then read through the entire thread. Much more educated than many on Bitcointalk.. You can still doublespend with a 51% attack, nothing has changed about that attack vector |
|
|
|
We also have other stuff that needs testing
What is the best place to report on testing, specifically and especially problems observed? To incentivize testing, there should be a bounty pool for bug reports, based on severity of the problem, closed to developers and their associates. but the reporting channel should be closed, private, to avoid the possibility of exploits coming from that channel. For now, raise an issue in the github where you find them (or query those branch authors and tell them to allow issue reporting if it's not enabled). Part of the current money received to the donation address should be allowed to rewarding bugfinding and bugfixing, I agree. |
|
|
|
1000 blocks downloaded, 103k to go  If this does not get the thing to work, I DON'T care if it would be even a golden coin. Dev team should think about it BEFORE they even started publishing anything. And if dev team fails - success is equal to zero. Failure to cross-platform serialize was an internal failure from the ByteCoin code, hence we updated our codebase to include mnemonic seeds to generate keys that function easily across platforms. Unfortunately, we inherited a lot of bad code, but we're doing our best to fix it now. |
|
|
|
you can't really lose anything if you backup your .bin.keys
32 and 64bit are different keys... not same - just tested on 64-bit Windows - can't load wallet. The obvious answers here are: 1. Set up 64bit wallet, transfer coins. 2. Use deterministic wallet, wait for seed fixes in binaries, restore from seed on 64bit system. BACKUP AND ENCRYPT EVERYTHING ALONG THE WAY There's a branch that fixes restore here: https://github.com/tewinget/bitmonero/tree/restore-fixSo you can restore wallets from mnemonic phrases properly if you compile that on whatever system. |
|
|
|
you can't really lose anything if you backup your .bin.keys
32 and 64bit are different keys... not same - just tested on 64-bit Windows - can't load wallet. That's correct. Serialization is not the same. You need to save your mnemonic phrase that's generated when you first create the wallet. |
|
|
|
This is my problem with XMR. I always feel like i NEED to watch the price like a Hawk in order to protect my investment because inflation is so high. I feel I HAVE TO use the volatility of the price in order to increase my stack so XMR can be a good store of value.
I dont need to do this with bitcoin. I dont care about the short term price because it's such a good store of value.
I must be too heavily invested in XMR and this decrease my productivity.
The surefire way to lose money in investments is to listen to what the market says. As Benjamin Graham so simply put it, the market is like an insane bipolar man who comes to your door when you wake up screaming and telling you to buy or sell for some ridiculous reason, then returns hours later to tell you to have the opposite behaviour, but for an equally ridiculous reason. You wouldn't listen to this sort of person in real life, so why would you let the market woo you any moreso? The effect of the inflation rates being initially set very high for Monero so that anyone who has stepped in and discovered the technology within the first two years will be able to purchase the coin cheaply. This also means high volatility in the meantime, but you know the math, the applied cryptography, the eventual number of coins, and the people currently working on the development of the coin. These latter facts should have you figure out the true value of the cryptocurrency, regardless of what the market thinks, and should help you sleep at night. |
|
|
|
I know, GUI wallet is like the holy grail for Monero. Once that's achieved, price will go up like a rocket.
Unfortunately, this is a pretty common misconception. Even if Bitcoin had the world's shiniest QT GUI, no one would ever use Bitcoin if the daemon crashed every few hours, the wallet periodically screws up reporting the correct values and needs to be resync'd, and both the daemon and wallet randomly disconnected from one another and stopped obtaining input, which is what currently often happens with the CN core code. It's analogous to a cruise ship with a beautiful interior gallery and guest rooms, but which has massive apparent holes in the hull of their ship. No one in their right mind would step aboard. Most of our recent development has been ensuring that this stuff works properly: http://www.reddit.com/r/Monero/comments/29b8ll/testing_new_monero_features/ |
|
|
|
When integrating code from Monero that fixed the bug for the txmempool making blocks with no blockreward, the BCN devs neglected to limit the size of transactions produced by the wallet. So, net effect, the wallet is allowed to generate tx that are never allowed into the blockchain because they would make the block sizes too big. I have submitted a pull request to fix their problem: https://github.com/amjuarez/bytecoin/pull/24They should really review our code more carefully if they want to borrow it, and at least attribute us for it. |
|
|
|
This thread is pretty disturbing for multiple reasons.
1) Tons of posts about a stupid furry mascot. Who gives a shit. Lets focus on the actual coin and developments.
2) Devs making incredibly slow progress and not accepting any help. Almost no change in anything from last week missive to this week's. Still analying white paper?! WTF.
3) Still no decent website. Still not accepting help for making the website better.
4) Still no progress on size issue, and no mention of the analysis done that said that there is no way to accomplish the reduction unlike other coins.
There is a window of time you get to promote and grow a new technology and get the adoption curve exponential. If you miss it, you get to hang out with the 400 other coins that also missed it. I get no sense of urgency from the devs, and cannot for the life of me understand why they don't accept help. They say they have a team working on "it", but nothing makes much progress. So either the team is not very good, not big enough, or not focused enough. All of those would seem to indicate the solution is to expand and get more help, especially since its free with volunteers.
There are dozens of coins actively in development with strong teams trying to beat XMR. This community needs to wake up if its going to succeed.
The size issue for sends is fixed on tewinget's master, one of the exchange operators had trouble getting payments from it so we're being careful merging it, but we think it's an issue on their end |
|
|
|
You came up with a pound of optimism proof. Respect. Nevertheless, why Monero devs deny help, do not answer email dev@monero.cc, and can not fix just html-markup mistakes in official site? I do not speak about visual design - the less the design, the better of my opinion. Website has been extensively redesigned, we're just putting the finishing touches on it before we upload it |
|
|
|
Thank you, that is relieving. I am aware of possible security threats, but current lack of gui for Monero and instructions like "update your wallet exactly like this or lose your coins" seem downright nightmarish to me. Again, thank you.
There's never been a bug like that, there's just been some bugs with the wallet thinking money is spent when it isn't. As long as you have your .keys file or mnemonic phrase you've always been fine. |
|
|
|
does the monero missives coming today ?
fluffypony said he was working on it a lot yesterday; he's travelling to meet rpietila atm, so forgive the late missive. |
|
|
|
New commit pushed that limits max block size to 196.6 kb. Block propagation @ 1 min is dubious past that block size even with SHA256D, so we should be careful to build blocks large than that. We also have other stuff that needs testing if you're adventurous: Transaction splitting (no more "tx too big errors") https://github.com/tewinget/bitmoneroWallet operates without RPC presence and new RPC semantics: wallet RPC converted to use new transaction semantics
wallet RPC now uses wallet2::create_transactions and wallet2::commit_tx instead
of wallet2::transfer. This made it possible to add the RPC call /transfer_split, which
will split transactions automatically if they are too large. The old call to
/transfer will return an error stating to use /transfer_split if multiple
transactions are needed to fulfill the request. Massive amount of fixes for RPC and wallet stability and serialization: https://github.com/mikezackles/bitmonero/tree/daemonizeWrapper for wallet functions https://github.com/Neozaru/bitmonero/tree/wallet_wrapperLots more in the pipeline that's soon to be merged to master, stay tuned. |
|
|
|
Unfortunately the XMR guys got very badly organized recently. And getting worse day from day.
May be there are some internal problems inside the team?
So, what's the plan?
A lot of noise and chaos and less real work.
But was very enthusiastic start.
No bubble lasts long, it is clear. The question is "what is the good time to quit"?
Who's next taking the challenge?
I'm working with three different devs and we're pushing code to branches that's being tested daily. There aren't any internal problems, fluffypony is out with rpietila and Peter Todd in Europe right now discussing the future of the chain and engineering issues regarding it. There are many big things that will be rolled out in the coming months, so stay tuned. |
|
|
|
You guys are sensitive because you've been punched in the same spot so many times. It's good to point out that the archer post is full of falsehood, I guess, since really dumb people might take it seriously, but really it is so far over the top... I LOLed.
I'm sad to hear about the BCN hero puppets. I hope no one ever does anything similar in support of XMR. Such folly in this world.
It gets disappointing when you spend most of your free time, unpaid, trying to manage a bunch of the coin's development and people explode this stuff onto your thread. Everything we put towards bounties could also be used for BCN, like the GUI, the GPU miner, and pools, we contributed most of the optimized slow hash code and were never credited for it. We're also working on a thin client for Monero that is FOSS so people can use it on phones, etc, but we seem to get no recognition for our accomplishments. |
|
|
|
Many people have been asking when XMR block reward "halves", so I made a chart of average block reward per year. We began at ~17.6, now we're at about 16. Of course, the block reward decreases per block.  You can view the live chart here: http://monerochain.info/charts/rewardYear Average Block Reward
1 13.8360377478
2 8.3814854455
3 5.0772699203
4 3.0756683896
5 1.8631540556
6 1.1286467184
7 0.6837026768
8 0.4141679966
9 0.2508914111
10 0.1519830133
11 0.0920670672
12 0.0557716592
13 0.0337849144
14 0.020465958
15 0.0123977061
16 0.0075101844
17 0.0045494599
18 0.0027559359
19 0.001669469
20 0.0010113177 |
|
|
|
Oh great, is there a thread for infos and testing ?
No, he's still looking for investors, I went through the technicals of it with him though. If you want to talk to him re: investment/donation, he's on IRC. |
|
|
|
Just one proposal: Somebody was talking about the possibility to make a lightweight wallet, given the fact that the daemon and the wallet are running separately.
I would start considering this idea: It would be possible to provide something like an "official" daemon, with all the necessary measures to provide a reliable service (clusterized, HA, ...) as well as a smartphone wallet. If anybody could have on the smartphone a monero wallet, that would ease a lot a wide adoption, and even making XMR a viable payment method.
I would suggest the developers to think about that possibility.
zone117x is working on it already. |
|
|
|
|
I got the Chapter 11 claim yesterday.
As I got my units, vaguely on time as compared to their contract, I don't plan to complain at the current time. But I hope all of you guys can recoup something.
|
|
|
|
Hello. At first - thank you to interest to BBR project. This is simply not true. The main reason of using this approach was to solve hash speed problem and to keep memory hard, it was discussed in our pre launch pow discussion thread. Since cn_slow_hash created 2MB scratchpad, it's have to cover all this data, that's why they use 220 iterations, and side-effect from this pretty slow work (about 500ms on normal laptop, twice faster on normal pc with suitable cpu cache). It may slow down synchronisation process at downloading blockchain (that is not a big problem) and theoretically it may be possible to attack network - connect and send a random block to make peer calculate slow_hash for useless fake block.
So, putting all together, we want to have:
1. Wide CPU instruction set
2. Memory-oriented algo
3. Small work time.
Realizing it, we've tried to take a step to the side.
Idea of using blockchain data as scratchpad resulted in this hash function:
.......
That's my mistake, then. There's numerous discussions about it in this thread. Botnet resistance is only mentioned in passing. As far as memory hardness, whether or not this will ever be an issue on modern GPUs (whose onboard DRAM increases exponentially with Moore's law) given linear increases in memory for wild keccak with increasing chain size remains to be seen. As i understand from gmaxwell reply to me, he is also concerned about this security problem in monero/bcn.
This BBR feature at least provide a solution to solve this issue, unlike other cn projects including monero.
There are no identifer information in outs, taco, don't lie.
This is a policy attribute that can't provide more information about out than already exists in blockchain, but it will keep out untracebility property in safe(that can't be granted in monero).
This attributes also provide an ability to have public addresses that want to share their balance, public fund for example. Sending money to such fund with mixin attribute = 0 grant that this outs woun't be mixed and spending could be easily seen.
Sorry for bad english.
Zoidberg
gmaxwell brought up this point. You can distinguish users based on what mixin count they demand, which, like amounts, can be used for identification. Similar issues exist for payment IDs, which I refuse to use. Monero is actively solving this issue, and we will have a proposal and fix out in the near future. PS: this is funny that you blame my project, but take my commits less that in few in hours. We have different design intentions, and disagree about what features should and should not be implemented. I have complimented your bugfixes on the network/core before, but I can't agree with everything you engineer, as probably you will not agree with everything I engineer. |
|
|
|
|
Show Posts
