Well, me and someone else personally destroyed 600 by accident, I'm sure there will be more. Additionally, it's likely that hundreds or thousand of monero were lost due to TFT's block reward bug: http://monerochain.info/charts/rewardWhat did you accidentally do? Is it a pitfall others could avoid if you tell us?  [/quote] Check out the behaviour of "make clean" in the makefile Before I changed it, it didn't used to prompt you to remove the build directory... |
|
|
|
I am trying to follow the instruction to get my wallet setup in Windows but I am having no luck. I have all the files and have downloaded the latest blockchain.bin from the OP but my wallet just keeps saying:
"Failed to connect to any of seed peers, continuing without seeds"
Can anyone provide any info on what I may have wrong?
TFT pulled his seed nodes, you need to add new ones: bitmonerod --seed-node 62.210.78.186:18080 --seed-node 195.12.60.154:18080 --seed-node 54.241.246.125:18080 --seed-node 107.170.157.169:18080 --seed-node 54.207.112.216:18080 --seed-node 78.27.112.54:18080 --seed-node 209.222.30.57:18080 --seed-node 80.71.13.55:18080 --seed-node 107.178.112.126:18080 |
|
|
|
Thanks for your answer. I will take your advice.
I was using v0.8.8.2.1. The last mandatory update I see was to 0.8.8, so the version was up to date or am I wrong?
That version is old, there were some issues with versioning numbers before, so we had to roll back the numbering. Please download the version in the OP and use that. |
|
|
|
No. You can eliminate the dust simply by sending a series of tx to a new wallet to amalgamate it, though.
Yes, if only 0.5 XMR is able to be sent at a time at a 0.05 tx fee we are eating up 10%. Or am i misinformed? Fee is 0.005 XMR per tx, minus dust producing fees (with mixin 0 and output that is 0.5, you shouldn't be generating dust) |
|
|
|
My issue from the this post https://bitcointalk.org/index.php?topic=583449.msg7240988#msg7240988is still not fixed. The first transaction is finalized (after many hours) but the other one is not. This is just the only one monero lost. Anyway could be really more and nobody can tell me what did I do wrong. If there's nothing I did wrong and nothing I can do - the issue is appalling. Could literally mean: monero can disappear for no clear reason and be gone forever. You sent them using the old version of the client, there was a mandatory update weeks ago. I can tell because of the tx size limit in your console. You included txs that were likely both oversize and had the wrong fees. Please download the latest version of the software, delete your poolstate.bin file, delete your wallet.dat file (backup first), and resync from your wallet.dat.keys file. |
|
|
|
Hey all! I follow this thread regularly and mine Monero as well. I will have this dust problem soon when I transfer some to another wallet. NOW, I have a question for you guys.
The dust problem is because of so many smaller transactions adding up to send a larger problem correct?
SO, can I avoid this dust problem by buying a larger amount of Monero thereby creating a large incoming transaction and then sending the amounts through?
Any thoughts on this? I am going to be mining at a smaller pool as well to solve this issue.
No. You can eliminate the dust simply by sending a series of tx to a new wallet to amalgamate it, though. |
|
|
|
Actually, that's a good idea. Don't solve the dust problem for the pools and get all the devs together and suddenly come out with a solution for p2pool. Boom p2pool is the only dust free pool. Then solve it for other pools. p2pool is the only known way to solve the centralization problem right now. If you guys did that I think you'd become a threat to Bitcoin over night, and make a shitload of money in the process.
The P2Pool codebase is a nightmare and needs to be totally refactored. Additionally, verification of chains is extremely difficult due to the slowness of our hashing algorithm. I doubt it will be possible for a P2Pool implementation to come out in the near future (though I'd welcome it). The dust issue can be solved for pools simply by sending amounts denominated to 0.1 and nothing less, zone177x is working on it. |
|
|
|
Hi, monero developers (if you do periodically read this thread)! I have seen monero sources - their code style seems to be more clear than even bitcoin one  One question intrigues me: What elliptic curve criptography implementation do you use? Have you gotten it from another source? Or did you completely write it from scratch? ------- P.s. 'Contact' division in the official site http://monero.cc does not work - I can not send a message (replies "405 Not Allowed"). P.p.s. Do you need free class 'A' certificates from globalsign as an open source project? https://www.globalsign.com/ssl/ssl-open-source/EdDSA, see the ByteCoin whitepaper. We are using a reference implementation. See here for the advantages this has against Bitcoin's implementation: http://blog.cr.yp.to/20140323-ecdsa.html |
|
|
|
why is the difficulty and hashrate skyrocketing?
ec2 miners are launching hundreds of instances because it is extremely profitable with this price spike. Yup. The high inflation of this coin in the first couple of years likely ensures we will not have outrageous price pumps because people will simply turn on bulk computing farms if there are price spikes, and XMR will be dumped due to economic pressure. I'm not sure this is a bad thing. |
|
|
|
Any big holders? How many 25k+ holders are out there?
Impossible to tell because the blockchain is obfuscated (unless people give their viewkeys) |
|
|
|
And gmaxwell has NEVER endorsed Monero...
Though he has praised the BCN team and their CN tech...
And has specifically, publically condemned the Monero group as a bunch of thieves...
The exact discussion is out there... we will have to revisit it on a regular basis.
I doubt gmaxwell feels one way or the other -- he just thought the ring signature technique for obfuscating inputs was neat. Anyway, I'm not here to turf the BCN thread and I'm thankful for their codebase, I just wish they would coordinate with us a bit better so we can both work on improving our respective projects. |
|
|
|
You mean they'll be linked together from the exchange point of view?
What is the maximum length of the payment ID? Is it long enough to provide a monero address?
You will be able to search the blockchain after for all tx that have that payment ID, because it's cleartext. Of course, it doesn't necessarily mean tx are related, but if you keep using the same ID to send to the exchange... 256-bits. |
|
|
|
ok - so the payment ID is just a kind of user annotation on the transaction. Presumably then I can add it even if it isn't needed at the other end but if an exchange specifies one for deposits then I must use their specified one.
Is that it ?
Yes. You should use unique payment IDs each time, otherwise your tx will become linked together. |
|
|
|
For the sake of clarity can we eradicate all references to bitmonero now? I see some instances on github and elsewhere still using the old term.
This will be changed in the coming week as we move to monero-developers on github. |
|
|
|
Master has been updated - New seed nodes added. - Electrum-style deterministic wallets have been added to help in the recovery of your wallet should you ever need to. It is enabled by default. https://github.com/monero-project/bitmonero |
|
|
|
|
So far two pizza recipients have come forward and we're making arrangements.
If you are a pizza sender or receiver, please contact me ASAP!
|
|
|
|
Would fixing the rate at 1 Monero per block be too much?
I much prefer the immortal final reward to be something really nice and even, like 1 instead of 0.1 or 0.12.
I feel this might be ok because Monero is quite a fast release coin with 80% mined in the first 4 years. I really think we could justify 1 Monero per block.
I still prefer something like 0.5% - 1%
Someone said that 0.69% is the same as the doubling of the coin supply every 100 years (not including lost coins). I liked that idea.
I think we need to have a simple solution (fixed % or amount) without worrying about lost coins. Over time there will be less and less lost coins and I doubt we'll ever have the same lost coin situation as Bitcoin.
Monero is worth about $1 in it's first month, it took Bitcoin years to get to that point.
Well, me and someone else personally destroyed 600 by accident, I'm sure there will be more. Additionally, it's likely that hundreds or thousand of monero were lost due to TFT's block reward bug: http://monerochain.info/charts/reward |
|
|
|
anyone encountered this:
2014-Jun-10 21:48:30.221484 bitmonero v0.8.8.1(0.1-g328a52a)
2014-Jun-10 21:48:30.257486 Module folder: D:\coin\MRO\MROwallet\bitmonerod.exe
2014-Jun-10 21:48:30.261486 Initializing p2p server...
2014-Jun-10 21:48:30.264486 Binding on 0.0.0.0:18080
2014-Jun-10 21:48:30.290488 Net service binded on 0.0.0.0:18080
2014-Jun-10 21:48:30.292488 Attempting to add IGD port mapping.
2014-Jun-10 21:48:31.701568 ERROR c:\temp\monero\git-experimental\bitmonero-0.8.8update-x64\src\p2p\net_node.inl:247 UPNP_AddPortMapping failed.
2014-Jun-10 21:48:31.707569 P2p server initialized OK
2014-Jun-10 21:48:31.710569 Initializing cryptonote protocol...
2014-Jun-10 21:48:31.712569 Cryptonote protocol initialized OK
2014-Jun-10 21:48:31.715569 Initializing core rpc server...
2014-Jun-10 21:48:31.717569 Binding on 127.0.0.1:18081
2014-Jun-10 21:48:31.720570 Core rpc server initialized OK on port: 18081
2014-Jun-10 21:48:31.723570 Initializing core...
2014-Jun-10 21:48:31.726570 Loading blockchain...
2014-Jun-10 21:48:31.811575 Blockchain initialized. last block: 0, d706.h8.m48.s31 time ago, current difficulty: 1
2014-Jun-10 21:48:31.816575 Core initialized OK
2014-Jun-10 21:48:31.818575 Starting core rpc server...
2014-Jun-10 21:48:31.821575 Run net_service loop( 2 threads)...
2014-Jun-10 21:48:31.833576 [SRV_MAIN]Core rpc server started ok
2014-Jun-10 21:48:31.835576 [SRV_MAIN]Starting p2p net loop...
2014-Jun-10 21:48:31.838576 [SRV_MAIN]Run net_service loop( 10 threads)...
2014-Jun-10 21:48:32.838633 [P2P4]
**********************************************************************
The daemon will start synchronizing with the network. It may take up to several hours.
You can set the level of process detailization* through "set_log <level>" command*, where <level> is between 0 (no details) and 4 (very verbose).
Use "help" command to see the list of available commands.
Note: in case you need to interrupt the process, use "exit" command. Otherwise, the current progress won't be saved.
**********************************************************************
2014-Jun-10 21:48:51.171682 [P2P5]Failed to connect to any of seed peers, continuing without seeds
2014-Jun-10 21:49:08.803691 [P2P9]Failed to connect to any of seed peers, continuing without seeds
2014-Jun-10 21:49:26.114681 [P2P4]Failed to connect to any of seed peers, continuing without seeds
2014-Jun-10 21:49:46.739860 [P2P4]Failed to connect to any of seed peers, continuing without seeds
2014-Jun-10 21:50:04.357868 [P2P7]Failed to connect to any of seed peers, continuing without seeds
2014-Jun-10 21:50:25.019050 [P2P6]Failed to connect to any of seed peers, continuing without seeds
Same computer, QCN and FCN is OK, but MRO fail to connect.
We need more seed peers. Ask someone here for their p2pstate.bin files. |
|
|
|
|
Show Posts
