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

[numismatist]

Ultimately we aren't preventing anyone from writing an additional implementation and submitting a PR, and we will at the very least have a BerkleyDB fall-back implementation for environments that don't play well with large MMAPs.

Hmm... BerkleyDB is a typo? Bitcoin itself had migrated from BerkleyDB to LevelDB...

Meanwhiles, on http://coinmarketcap.com/currencies/views/filter-non-mineable-and-premined/ MonaCoin gets ready to buypass Monero, just mentioning. Rises 9.20 % whereas Monero does -7.17 %

[1713968994]

1713968994

[1713968994]

1713968994

[1713968994]

1713968994

[1713968994]

1713968994

[1713968994]

1713968994

[1713968994]

1713968994

[fluffypony]

Code:

get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

get_bulk_payments does give information like block height/payment id for the incoming tx (which you want to know if you want to wait for N confirmations before crediting), and has a min_block_height which hte other doesn't. So using incoming_transfers would need one such call plus a call per new incoming tx to get that other data.

What I mean is that we won't be providing a get_bulk_payments call that doesn't take a list of payment IDs (at this stage). We are designing a successor to the payment ID protocol, but typically speaking you will still need to know what you're scanning for (whether it is a payment ID "generated" by the recipient or one given to the recipient by the sender).

[GingerAle]

Ultimately we aren't preventing anyone from writing an additional implementation and submitting a PR, and we will at the very least have a BerkleyDB fall-back implementation for environments that don't play well with large MMAPs.

Hmm... BerkleyDB is a typo? Bitcoin itself had migrated from BerkleyDB to LevelDB...

Meanwhiles, on http://coinmarketcap.com/currencies/views/filter-non-mineable-and-premined/ MonaCoin gets ready to buypass Monero, just mentioning. Rises 9.20 % whereas Monero does -7.17 %

https://www.allcoin.com/trade/MONA_BTC

p.n.d.

[David Latapie]

I see one use of multiple addresses: when you don't want to know that two transactions go to the same address (like if you don't want people to find you by googling your address which is on bitcointalk signature of profile, or openalias, for instance).
But since there is no much of these needs, you may as well just use a second wallet.

It doesn't matter if your address is known, as it's impossible (with our current cryptography) to analyse the blockchain and find transactions you were involved in. Even if that was possible it still wouldn't be disastrous, as all that can be observed are transactions you *may or may not* have been involved in (thanks to ring signatures). The only time multiple wallets are necessary are for separating your personal and business accounts, for instance, or for a company that wants each department to have its own address and accounts.

I was more thinking about the same address being a signature on weloveteddybears.com and gunenthusiast.com.
Pippo, to decide about Monero:

1. Follow this link: https://xmrmonero.com/faq/en/monero-matters
2. Follow all the links (some are just one post to read,not the whole thread)

If you are interested in the vision and the philosophy of the dev team, I recommand you "Three Pillars of Monero" if you want to know about the vision and spirit
If you are more interested in "Monero vs Darkcoin", read my comment on "Darkcoin, Anoncoin, Shadowcash, Monero"

You should have a good summary. We are working on creating a more consolidated document.

[smooth]

I was more thinking about the same address being a signature on weloveteddybears.com and gunenthusiast.com.

It would certainly be a good idea for those to use different addresses, except perhaps in the case where they are both using third party payment processor, in which case sharing an address (with each other but also with many other businesses using the same payment processor) wouldn't mean anything at all.

[TheKoziTwo]

Code:

get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point? I guess with the parameter transfer_type "available" it won't be all that bad since most funds will be transferred elsewhere, but doesn't feel right to me. Also, is there any function to retrieve a payment_id with tx hash? without that this won't work anyways.

Polling get_bulk_payments with payment id's is fine too, except it will also grow too large at some point? As in, one may end up having to poll millions of payment ids. You could add the height parameter, but still, it just doesn't feel right having to run this through all payment_ids just to check for new transactions.

I'm thinking a simple get tx's/payment id's > height = new transactions for script to process.

Currently is seems to me I'll have to:
1. Record last checked height next to all payment ids in database.
2. Cron job traverse through all payment ids in database continuously checking for new tx's while also updating height

I must be missing something

[smooth]

Code:

get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point?

Maybe add an optional minimum height to incoming_transfers?

[TheKoziTwo]

Code:

get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point?

Maybe add an optional minimum height to incoming_transfers?

There is no such param atm afaik? Also that still leaves the other question, what function to get payment id from tx_id

[smooth]

Code:

get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point?

Maybe add an optional minimum height to incoming_transfers?

There is no such param atm afaik?

Yes, that's why I proposed adding one.

Also that still leaves the other question, what function to get payment id from tx_id

There doesn't seem to be one right now. You can get the tx in raw hex but you would have to decode it.

BTW, as far as I can tell from the code, if you do get_bulk_payments with an empty payment ID list you get all payments.

[David Latapie]

I significantly updated the FAQ entry for OpenAlias

New entry is https://xmrmonero.com/faq/openalias
The text is the one from www.http://reddit.com/r/Monero/comments/2uv214/what_is_openalias/ with some extras
1. Step-by-step instructions on how to create your own alias (as requested on the Monero forum) and link to saddam's giveaway
2. Creating an OpenAlias for another cryptocurrency
3. OpenAlias and .bit (Namecoin), including a hint for those who don't have a domain name and don't want to spend several euros per year just for that

[TheKoziTwo]

Code:

get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point?

Maybe add an optional minimum height to incoming_transfers?

There is no such param atm afaik?

Yes, that's why I proposed adding one.

I would prefer to have minimum height implemented in get_bulk_payments so that you do not have to enter payment id's.

Also that still leaves the other question, what function to get payment id from tx_id

There doesn't seem to be one right now. You can get the tx in raw hex but you would have to decode it.

BTW, as far as I can tell from the code, if you do get_bulk_payments with an empty payment ID list you get all payments.

I thought so at first too, but it doesn't work, I have to specify payment id's otherwise nothing is returned...

Code:

Code:

$r = $wallet->get_bulk_payments(json_encode(array('payment_ids'=>array())));
var_dump($r);

$r = $wallet->get_bulk_payments(json_encode(array('min_block_height'=>399206)));
var_dump($r);

$r = $wallet->get_bulk_payments(json_encode(array('payment_ids'=>array(),'min_block_height'=>399206)));
var_dump($r);

$r = $wallet->get_bulk_payments(json_encode(array('payment_ids'=>null)));
var_dump($r);

$r = $wallet->get_bulk_payments(json_encode(array('payment_ids'=>null,'min_block_height'=>399206)));
var_dump($r);

Result:

Code:

array (size=0)
  empty

array (size=0)
  empty

array (size=0)
  empty

array (size=0)
  empty

array (size=0)
  empty

[smooth]

I thought so at first too, but it doesn't work, I have to specify payment id's otherwise nothing is returned...

Try rebuilding the wallet

[TheKoziTwo]

I thought so at first too, but it doesn't work, I have to specify payment id's otherwise nothing is returned...

Try rebuilding the wallet

I don't have any build environment atm so I'm just using the pre-built binaries for this, as I stated previously the idea is that once finished, the public can download the complete integration and pre-built binaries and quickly integrate with their own service. Instead of everyone trying to figure it out by themselves. I am not interested in using any functions not available in the pre-built binaries.

Fluffypony said it's not going to be added. But if it's already added, all I'm asking is for a release date and I'll finish it of later, I'm in no hurry.

This is the code isn't it?

Code:

 /* If the payment ID list is empty, we get payments to any payment ID (or lack thereof) */
if (req.payment_ids.empty())
{
std::list<std::pair<crypto::hash,wallet2::payment_details>> payment_list;
m_wallet.get_payments(payment_list, req.min_block_height);
for (auto & payment : payment_list)
{
wallet_rpc::payment_details rpc_payment;
rpc_payment.payment_id = epee::string_tools::pod_to_hex(payment.first);
rpc_payment.tx_hash = epee::string_tools::pod_to_hex(payment.second.m_tx_hash);
rpc_payment.amount = payment.second.m_amount;
rpc_payment.block_height = payment.second.m_block_height;
rpc_payment.unlock_time = payment.second.m_unlock_time;
res.payments.push_back(std::move(rpc_payment));
}
return true;
}

That's why I asked, because I thought this code was doing what I asked for (just not in the binaries yet), but fluffy said no:

Code:

get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

[smooth]

I thought so at first too, but it doesn't work, I have to specify payment id's otherwise nothing is returned...

Try rebuilding the wallet

I don't have any build environment atm so I'm just using the pre-built binaries for this, as I stated previously the idea is that once finished, the public can download the complete integration and pre-built binaries and quickly integrate with their own service. Instead of everyone trying to figure it out by themselves. I am not interested in using any functions not available in the pre-built binaries.

Fluffypony said it's not going to be added. But if it's already added, all I'm asking is for a release date and I'll finish it of later, I'm in no hurry.

Fluffypony misunderstood either your inquiry or what had been added to the code, I'm not sure which.

When I said "rebuilding the wallet" I meant delete the wallet.bin file. (But this assume you are using the code that has support for the empty-list payment ID request.)

The list of payments is stored in the wallet.bin file and doesn't include payments without an ID if they were received and processed using the old code.

As far as a release date for the next official build of the code, I don't know. Maybe you can get a trusted person to create a custom build for you?

[TheKoziTwo]

I thought so at first too, but it doesn't work, I have to specify payment id's otherwise nothing is returned...

Try rebuilding the wallet

I don't have any build environment atm so I'm just using the pre-built binaries for this, as I stated previously the idea is that once finished, the public can download the complete integration and pre-built binaries and quickly integrate with their own service. Instead of everyone trying to figure it out by themselves. I am not interested in using any functions not available in the pre-built binaries.

Fluffypony said it's not going to be added. But if it's already added, all I'm asking is for a release date and I'll finish it of later, I'm in no hurry.

Fluffypony misunderstood either your inquiry or what had been added to the code, I'm not sure which.

When I said "rebuilding the wallet" I meant delete the wallet.bin file. (But this assume you are using the code that has support for the empty-list payment ID request.)

The list of payments is stored in the wallet.bin file and doesn't include payments without an ID if they were received and processed using the old code.

As far as a release date for the next official build of the code, I don't know. Maybe you can get a trusted person to create a custom build for you?

Right, I just tried rebuilding the wallet, doesn't work. I'm running version 0.8.8.6. No worries, I'm just going to wait until the new release is out. But it would be great if fluffy could confirm this, because if it turns out this code will not be added, I will just go ahead with the proposed solution even though it's not optimal.

[smooth]

Right, I just tried rebuilding the wallet, doesn't work. I'm running version 0.8.8.6.

Yes that's right. Version 0.8.8.6 is from December 8 and the relevant code was added on January 10: https://github.com/monero-project/bitmonero/commit/87839cd4843efb231f0406881437d724dbf0161c

So you will need a build newer than that to be able to retrieve all payments.

[TheKoziTwo]

Ok cool, I'll wait for the new version to be released and continue development then.

[GingerAle]

Unofficial Monday Moneroworld Digest

Prettiest

https://forum.monero.cc/20/general-discussion/147/weekly-monero-digest-feb-2nd-feb-9th-2015-pg-1016-1025

Backup

http://xmrmonero.com/forum/monday-moneroworld-digest-2015-02-09

I got tired of everyone wanting a monday missive. So I made one. Because thats what we do in moneroworld.

[smooth]

So I made one. Because thats what we do in moneroworld.

Bravo

[Hueristic]

Unofficial Monday Moneroworld Digest

Prettiest

https://forum.monero.cc/20/general-discussion/147/weekly-monero-digest-feb-2nd-feb-9th-2015-pg-1016-1025

Backup

http://xmrmonero.com/forum/monday-moneroworld-digest-2015-02-09

I got tired of everyone wanting a monday missive. So I made one. Because thats what we do in moneroworld.

What a great synopsis!