[XMR] Monero - A secure, private, untraceable cryptocurrency

[rramires]

Hi,

I'm testing RPC calls with the aim of creating my wallet, using AS3/Flex:

public function call():void
{
   httpService.url = "http://127.0.0.1:18081/json_rpc";
   httpService.contentType = "application/json";
   httpService.method = "POST";
   httpService.resultFormat = HTTPService.RESULT_FORMAT_TEXT;
   
   
   var obj:Object = new Object();
      obj.jsonrpc = "2.0";
      obj.id = "1";
      obj.method = "getblockcount";
      //obj.params = {};
   
   var strJson:String = JSON.stringify(obj);
   
   serviceHelper.executeServiceCall(httpService.send(strJson), testeResult);
}


private function testeResult(r:Object):void
{
   trace("testeResult: " + r.result);
   
   var resObj:Object = JSON.parse(r.result);
}

OK, says:

testeResult: {
  "id": "1",
  "jsonrpc": "2.0",
  "result": {
    "count": 134310,
    "status": "OK"
  }
}

But I wonder if the commands of the wallet can be accessed, eg "getbalance" says:

testeResult: {
  "error": {
    "code": -32601,
    "message": "Method not found"
  },
  "id": "1",
  "jsonrpc": "2.0"
}

Where do I find the list of commands? Is there any technical topic?

[1714985369]

1714985369

[1714985369]

1714985369

[1714985369]

1714985369

[1714985369]

1714985369

[1714985369]

1714985369

[hitbtc]

Dear members of the community! Lately we have been paying close attention to Monero’s trading dynamics on our exchange and as we have already mentioned earlier they are getting better with each passing day.

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!

[superresistant]

https://i.imgur.com/fwunsgd.jpg
https://i.imgur.com/idmcfuY.png

looks like he is farting fire

[aminorex]

...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.

[Qsquegg]

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!

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 

[fluffypony]

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).

[nakaone]

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?

[AceCobra1]

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

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

[fluffypony]

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.

[rramires]

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.

[perl]

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

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.

[rramires]

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.

[superresistant]

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

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

[jurjtney0]

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

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.

Win 7 x64, 8gb ram, i5-2500@3.3, >50GB disk space available. Errors were simply - finding that block X is orphaned, resync, Block X is orphaned...
 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.

[aminorex]

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.

[HolyTrumpet]

...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.

[fluffypony]

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.

[rramires]

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.

[fluffypony]

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.

Don't worry, we don't write things off just because it appears ill-suited at first glance - it's on the testing list:)

[nexern]

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?