Has there been any new CPU miners released in the past few weeks?
Yam and Wolf0's miner seem to be the best, but wondering if there were more or a higher hash rate branch.
Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1620. (Read 4670972 times)
Agreed HitBTC is getting pretty silly. I was considering sending some BTC there until they started the childish campaigns and overusing Luke. To the moon campaign? Seriously? Are they a professional exchange or some kind of joke. Do they really need to be in the thread title?
thx for guiding fluffypony.
just chimed in, interesting project.
yes, sqlite is nice code but not suitable to store a blockchain.
beside speed, predictable fetch timing and execution costs when chaining key requests are vital and a big plus for kv.
while leveldb is well known, there are many other kv's available to choose from. good to hear you are using kv.
btw, is there any running testnet accessible for external devs?
yes, sqlite is nice code but not suitable to store a blockchain.
beside speed, predictable fetch timing and execution costs when chaining key requests are vital and a big plus for kv.
while leveldb is well known, there are many other kv's available to choose from. good to hear you are using kv.
btw, is there any running testnet accessible for external devs?
There's a testnet that's WIP at the moment: https://github.com/mikezackles/bitmonero/tree/testnet - there's still a bit that needs to be done before it's merged in, but it'll be quite soon as there's stuff that needs testing on testnet.
just chimed in, interesting project.
yes, sqlite is nice code but not suitable to store a blockchain.
beside speed, predictable fetch timing and execution costs when chaining key requests are vital and a big plus for kv.
while leveldb is well known, there are many other kv's available to choose from. good to hear you are using kv.
btw, is there any running testnet accessible for external devs?
yes, sqlite is nice code but not suitable to store a blockchain.
beside speed, predictable fetch timing and execution costs when chaining key requests are vital and a big plus for kv.
while leveldb is well known, there are many other kv's available to choose from. good to hear you are using kv.
btw, is there any running testnet accessible for external devs?
Test the performance before deciding discart. My company is developing a CAT:
http://en.wikipedia.org/wiki/Computer-assisted_translation
Our searches in database are extremely heavy.
http://en.wikipedia.org/wiki/Computer-assisted_translation
Our searches in database are extremely heavy.
Don't worry, we don't write things off just because it appears ill-suited at first glance - it's on the testing list:)
Consider SQLite 3, I am using a project that stores large amounts of data on the client and is doing well.
I hope the criteria for db selection focus primarily on functional coverage and orthogonality and portability (platform and skill) and ignore linear speed factors. I have had really good luck with SQLite3 as well.I understand the instinct, but SQLite is an RDBMS, and as such it is ill-suited to this. Functionality will be provided through RPC calls, not by sacrificing speed because we implemented an entire RDBMS (albeit one that is self-contained). The blockchain needs to be in a fast key-value store so that commonly hit functions (network catch-up, scanning when restoring a wallet or re-syncing one, key image scanning for double-spend prevention) are blazingly fast both now and in future. Given the size of the key image table / index, it would take tens of seconds for you to send a transaction if we used SQLite.
Of course, the fact is that we are abstracting the DB functionality, so someone else can have an active fork that uses SQLite.
Test the performance before deciding discart. My company is developing a CAT:
http://en.wikipedia.org/wiki/Computer-assisted_translation
Our searches in database are extremely heavy.
Consider SQLite 3, I am using a project that stores large amounts of data on the client and is doing well.
I hope the criteria for db selection focus primarily on functional coverage and orthogonality and portability (platform and skill) and ignore linear speed factors. I have had really good luck with SQLite3 as well.I understand the instinct, but SQLite is an RDBMS, and as such it is ill-suited to this. Functionality will be provided through RPC calls, not by sacrificing speed because we implemented an entire RDBMS (albeit one that is self-contained). The blockchain needs to be in a fast key-value store so that commonly hit functions (network catch-up, scanning when restoring a wallet or re-syncing one, key image scanning for double-spend prevention) are blazingly fast both now and in future. Given the size of the key image table / index, it would take tens of seconds for you to send a transaction if we used SQLite.
Of course, the fact is that we are abstracting the DB functionality, so someone else can have an active fork that uses SQLite.
...stuff...
I appreciate your support for XMR and all, but really, shouldn't you get your own thread for this?
Not that this thread is particularly well curated, but it is getting a bit much, IMO.
You're right, nothing, including this shitty exchange's campaigns, will save this dumb coin from the inevitable dump and oblivion.
Consider SQLite 3, I am using a project that stores large amounts of data on the client and is doing well.
I hope the criteria for db selection focus primarily on functional coverage and orthogonality and portability (platform and skill) and ignore linear speed factors. I have had really good luck with SQLite3 as well. What details? Daemon was shut down for 3 days, started - no sync for hours.
Deleted blockchain, resync - all is fine by magic.
Until blockchain bloat&problems are solved long term future for cryptonight is not good
PS: And having daemon which sucks GB ram and lots of cpu&bandwidth running 24/7 is unacceptable
Deleted blockchain, resync - all is fine by magic.
Until blockchain bloat&problems are solved long term future for cryptonight is not good
PS: And having daemon which sucks GB ram and lots of cpu&bandwidth running 24/7 is unacceptable
Details would include things like your operating system, CPU/RAM/available disk space, what errors show up in the daemon window (if any).
Your next step would be to check if there is an open github issue for the problem you're facing, and if not you should open one: https://github.com/monero-project/bitmonero/issues
At the end of the day, this is an open-source project that is in very early alpha stages, and you are most welcome to fix the problems you've described and submit your code via a pull-request.
After redownloading blockchain from post 1 it resynced for 5 minutes. But downloading 3 times in a month 1.5GB blockchain is not good
. I always close the daemon after save with exit...and when I started it actually moved several hundred blocks ahead before entering orphan loop This time I won't delete downloaded blockchain . I had once a similar problem and solved it due to deleting p2pstate.bin and poolstate.bin in appdata/roaming/bitmonero.
But im not realy the tech-guy so only try on your own risk. Maybe a dev can answer if this action could solve your problem.
btw, I am mining at http://monero.crypto-pool.fr/
I saw this transaction last night... any ideas:
17/7/2014 23:13:51 -0.800000000000 <0ced61d7bf937af91a84f36227bb8da7fa1773d25f715790647e3200f605a8ba>
Got monero taken off me lol
I saw this transaction last night... any ideas:
17/7/2014 23:13:51 -0.800000000000 <0ced61d7bf937af91a84f36227bb8da7fa1773d25f715790647e3200f605a8ba>
Got monero taken off me lol
It is normal.
The transaction was invalid so I credited your account back.
We are monitoring all transactions to ensure all payment are made.
Thank you for your trust.
FIFY
At the moment, bandwidth and ram issues are of the highest priority.
can someone give an eli5/eli10 update on the progress of this issue. I am from the non-technical/economics perspective, but for me this is of a high priority regarding investment decisions, I am not in a hurry, so if this needs time it is no problem at all.
RAM issues are being solved by moving to an embedded database, thus negating the need for the whole blockchain to be loaded into RAM when Monero is running. The current progress of this is occurring in this branch on github: https://github.com/tewinget/bitmonero/tree/blockchain - currently the work is focused around very generic code to do allow for the blockchain to live in an embedded database. I hate putting timelines down, as there are moving goal posts and the amount of time that we spend actively developing is dependent on how much time we can free up from other projects via donations, but I'm confident that we'll start testing different embedded databases within a week or so. After we've determined which is most suited to our workload, we'll finalise the integration and start proper testing on testnet, after which we can get some of the smaller pools to make the switch and see how it holds up, and then we will release it as part of the main system.
Bandwidth issues are being solved by a "quality of service" system that will allow for limitations on a bandwidth level. There's been a stack of work that was done on that over the past 2 days that hasn't been pushed up to a branch yet, but barring a little bit of cleaning up this should hopefully be ready for testing within a few days.
Consider SQLite 3, I am using a project that stores large amounts of data on the client and is doing well.
btw, I am mining at http://monero.crypto-pool.fr/
I saw this transaction last night... any ideas:
17/7/2014 23:13:51 -0.800000000000 <0ced61d7bf937af91a84f36227bb8da7fa1773d25f715790647e3200f605a8ba>
Got monero taken off me lol
I saw this transaction last night... any ideas:
17/7/2014 23:13:51 -0.800000000000 <0ced61d7bf937af91a84f36227bb8da7fa1773d25f715790647e3200f605a8ba>
Got monero taken off me lol
It is normal.
The transaction was invalid so I credited your account back.
We are monitoring all transactions to insure all payment are made.
Thank you for your trust.
Where do I find the list of commands? Is there any technical topic?
We're busy putting together specifications for this - we've made a number of changes from the reference code, so checking the two RPC maps in the source code is your best bet right now.
Also, you can't run wallet commands against the daemon - the daemon is not a wallet, it just syncs up to the network. You'd run wallet RPC calls against simplewallet in RPC mode, but bear in mind that it is being deprecated in favour of a drop-in replacement called rpcwallet (dev branch for this is linked in the last Missive iirc).
OK, thanks I'll wait rpcwallet be ready to continue my experiments.
Is it:
https://github.com/tewinget/bitmonero/tree/rpcwallet/src/rpcwallet
I want to make an UI using Adobe AIR, for ease of translation and to be multiplatform.
At the moment, bandwidth and ram issues are of the highest priority.
can someone give an eli5/eli10 update on the progress of this issue. I am from the non-technical/economics perspective, but for me this is of a high priority regarding investment decisions, I am not in a hurry, so if this needs time it is no problem at all.
RAM issues are being solved by moving to an embedded database, thus negating the need for the whole blockchain to be loaded into RAM when Monero is running. The current progress of this is occurring in this branch on github: https://github.com/tewinget/bitmonero/tree/blockchain - currently the work is focused around very generic code to do allow for the blockchain to live in an embedded database. I hate putting timelines down, as there are moving goal posts and the amount of time that we spend actively developing is dependent on how much time we can free up from other projects via donations, but I'm confident that we'll start testing different embedded databases within a week or so. After we've determined which is most suited to our workload, we'll finalise the integration and start proper testing on testnet, after which we can get some of the smaller pools to make the switch and see how it holds up, and then we will release it as part of the main system.
Bandwidth issues are being solved by a "quality of service" system that will allow for limitations on a bandwidth level. There's been a stack of work that was done on that over the past 2 days that hasn't been pushed up to a branch yet, but barring a little bit of cleaning up this should hopefully be ready for testing within a few days.
btw, I am mining at http://monero.crypto-pool.fr/
I saw this transaction last night... any ideas:
17/7/2014 23:13:51 -0.800000000000 <0ced61d7bf937af91a84f36227bb8da7fa1773d25f715790647e3200f605a8ba>
Got monero taken off me lol
I saw this transaction last night... any ideas:
17/7/2014 23:13:51 -0.800000000000 <0ced61d7bf937af91a84f36227bb8da7fa1773d25f715790647e3200f605a8ba>
Got monero taken off me lol
That's not a valid transaction: http://monerochain.info/tx/0ced61d7bf937af91a84f36227bb8da7fa1773d25f715790647e3200f605a8ba - is that a key image for an input or a tx id?
not sure what it is - it is on my page when i click get detailed payouts and is the only transaction that shows as a negative (bearing in mind I have been connected to that website for about the last 4 - 5 weeks!) - nothing major but just wondering what it was
At the moment, bandwidth and ram issues are of the highest priority.
can someone give an eli5/eli10 update on the progress of this issue. I am from the non-technical/economics perspective, but for me this is of a high priority regarding investment decisions, I am not in a hurry, so if this needs time it is no problem at all.
anyone? developers?
Where do I find the list of commands? Is there any technical topic?
We're busy putting together specifications for this - we've made a number of changes from the reference code, so checking the two RPC maps in the source code is your best bet right now.
Also, you can't run wallet commands against the daemon - the daemon is not a wallet, it just syncs up to the network. You'd run wallet RPC calls against simplewallet in RPC mode, but bear in mind that it is being deprecated in favour of a drop-in replacement called rpcwallet (dev branch for this is linked in the last Missive iirc).
The confidence that you have put in us and your willingness to keep the coin alive and well by trading it in ever-increasing volumes are invaluable to us. And because of that we have decided to announce yet another exciting campaign.
The two people who will buy Monero at our exchange at the highest price until today’s and tomorrow’s midnight UTC will get a 100 XMR reward!
The two people who will buy Monero at our exchange at the highest price until today’s and tomorrow’s midnight UTC will get a 100 XMR reward!
that's a lot of campaigns going on, lol. well, at least it's something other than constant discussions of wallet issues and stuff
looks like he is farting fire
his ass is on fire because he's raging after aminorex telling him to go away
Jump to: