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

[shitaifan2013]

In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client?

There is no reason. Someone just needs to define a format, implement it, pull request. Done.

I'm not familiar enough with the codebase to do it myself, but if it's a simple task I'll throw 100 xmr to whoever can get it in.

adding 100XMR to that bounty   

[Bassica]

Add another 50.

[fluffypony]

I don't remember who stated it above, but I do agree that the lack of exchange/merchant adoption might have something to do with the hassle of depending on users to include payment IDs.

Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.

No checksum is one reason why this will potentially backfire. That and the payment ID space is unnecessarily huge.

I'll take a look at my notes from the MRL meetup in November last year, we had some ideas about fixing the payment ID format and serialising it, there may be a quick win to be had whilst we chip away at the stealth payment IDs.

[smooth]

I don't remember who stated it above, but I do agree that the lack of exchange/merchant adoption might have something to do with the hassle of depending on users to include payment IDs.

Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.

No checksum is one reason why this will potentially backfire. That and the payment ID space is unnecessarily huge.

I'll take a look at my notes from the MRL meetup in November last year, we had some ideas about fixing the payment ID format and serialising it, there may be a quick win to be had whilst we chip away at the stealth payment IDs.

I disagree that we need to do nothing while we work on something better (obviously one does not preclude the other at all).

There is no checksum now. The length and valid characters are checked but that's it. The exact same thing can still be checked if the format is changed, slightly to something like

Code:

Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em-e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac

Instead of

Code:

Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em

and use this payment ID

e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac

It is the exact same thing in terms of checksums, validation, etc. except that the second is far more likely to lead to people forgetting it or not understanding it, and also fits worse with the usual workflow of a btc-style coin where people generate new addresses for each customer/invoice/etc., and has a higher support burden. With the first method, you have have the exact same kind of button in an exchange wallet window that says "generate new address" and it can go ahead and generate a new address that happens to share the same prefix, instead of needing something different for "payment-id coins".

We're suffering this unnecessary mismatch from the usual model and confusion because the cryptonote/BCN guys didn't see the need for a payment ID at all in their earlier design at all and threw the payment ID on there later as an extra thing instead of including it in addresses (there are commits in their repo when they added it, so it is clear it was an added patch). If it were part of the original design I bet something more like the prefix-suffix syntax would have been used.

[GTO911]

The cryptonote scammers came out with a reference QT GUI wallet

[smooth]

The cryptonote scammers came out with a reference QT GUI wallet

I wonder how it relates to the QT wallet that was part of Pebblecoin, does anyone know?

[MalMen]

I don't remember who stated it above, but I do agree that the lack of exchange/merchant adoption might have something to do with the hassle of depending on users to include payment IDs.

Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.

I think the bestway to solve this is using openalias, its already decided that we should use payment_id on openalias for setting an payment_id, but its not implemented on simplewallet nor on most famouse webwallet (mymonero), after that implementation it would be east for an exchange like poloniex to create openalias for each user with theyr payment_id, for example, malmen.xmradd.poloniex.com, i can help to implement this (i already have the knowage with http://xmr.link ), but this implementation its needed on the client side first....

[GingerAle]

WARNING - these are not "official", as in, someone from the core dev team didn't compile them and gave them the a-ok. I'm putting them here for testing purposes. I compiled following the instructions on the github. Perhaps they are static? Perhaps you can run the LMDB version of bitmonerod on your win 64 box and only use 50 megs of ram?

https://mega.co.nz/#!5YNACDTJ!N0pIow27_Tfsx4dMfMq4HA11ZSlEt7L135HvYEOuBU8

perhaps you can swap in the relevant .exe files from the above into the /resources/software/ folder of MoneroX you can have a monero GUI on windows 64 that sips RAM like a fine wine?

AGAIN - don't trust these. Test them until you trust them. Make sure they do everything they should do. I tested them on the box I compiled on and another windows 7 box.

Hopefully someone will post the data.mdb download link.  

( removed the converter thing)

wow, no takers? I thought "the drooling masses" would be all over this.

[Bassica]

WARNING - these are not "official", as in, someone from the core dev team didn't compile them and gave them the a-ok. I'm putting them here for testing purposes. I compiled following the instructions on the github. Perhaps they are static? Perhaps you can run the LMDB version of bitmonerod on your win 64 box and only use 50 megs of ram?

https://mega.co.nz/#!5YNACDTJ!N0pIow27_Tfsx4dMfMq4HA11ZSlEt7L135HvYEOuBU8

perhaps you can swap in the relevant .exe files from the above into the /resources/software/ folder of MoneroX you can have a monero GUI on windows 64 that sips RAM like a fine wine?

AGAIN - don't trust these. Test them until you trust them. Make sure they do everything they should do. I tested them on the box I compiled on and another windows 7 box.

Hopefully someone will post the data.mdb download link.  

( removed the converter thing)

wow, no takers? I thought "the drooling masses" would be all over this.

I'll pbb download it when I get home gingy, thanks.

[oblox]

WARNING - these are not "official", as in, someone from the core dev team didn't compile them and gave them the a-ok. I'm putting them here for testing purposes. I compiled following the instructions on the github. Perhaps they are static? Perhaps you can run the LMDB version of bitmonerod on your win 64 box and only use 50 megs of ram?

https://mega.co.nz/#!5YNACDTJ!N0pIow27_Tfsx4dMfMq4HA11ZSlEt7L135HvYEOuBU8

perhaps you can swap in the relevant .exe files from the above into the /resources/software/ folder of MoneroX you can have a monero GUI on windows 64 that sips RAM like a fine wine?

AGAIN - don't trust these. Test them until you trust them. Make sure they do everything they should do. I tested them on the box I compiled on and another windows 7 box.

Hopefully someone will post the data.mdb download link. 

( removed the converter thing)

wow, no takers? I thought "the drooling masses" would be all over this.

I'd be more interested in the data file for syncing purposes although at 16gb, not sure who's willing to host.

[iCEBREAKER]

The cryptonote scammers came out with a reference QT GUI wallet

I wonder how it relates to the QT wallet that was part of Pebblecoin, does anyone know?

I'd rather not know.  The Cryptonote Conspiracies' intrigues and mysteries are better left unresolved.   

[GingerAle]

WARNING - these are not "official", as in, someone from the core dev team didn't compile them and gave them the a-ok. I'm putting them here for testing purposes. I compiled following the instructions on the github. Perhaps they are static? Perhaps you can run the LMDB version of bitmonerod on your win 64 box and only use 50 megs of ram?

https://mega.co.nz/#!5YNACDTJ!N0pIow27_Tfsx4dMfMq4HA11ZSlEt7L135HvYEOuBU8

perhaps you can swap in the relevant .exe files from the above into the /resources/software/ folder of MoneroX you can have a monero GUI on windows 64 that sips RAM like a fine wine?

AGAIN - don't trust these. Test them until you trust them. Make sure they do everything they should do. I tested them on the box I compiled on and another windows 7 box.

Hopefully someone will post the data.mdb download link. 

( removed the converter thing)

wow, no takers? I thought "the drooling masses" would be all over this.

I'd be more interested in the data file for syncing purposes although at 16gb, not sure who's willing to host.

Luckily, for whatever reason, the linux data.mdb works in windows, and the linux data.mdb shows up as ~6 gigs until the windows bitmonero accesses it, and then it turns into 16 gigs (due to what fluffypony called windows not liking sparse files). And then, magically, when either of them are compressed, they go to around 3.5 gigs or something.

Regardless, the best thing would be to sync from scratch, independent of how long it takes, because, you, decentralization nom nom nom.

[oblox]

WARNING - these are not "official", as in, someone from the core dev team didn't compile them and gave them the a-ok. I'm putting them here for testing purposes. I compiled following the instructions on the github. Perhaps they are static? Perhaps you can run the LMDB version of bitmonerod on your win 64 box and only use 50 megs of ram?

https://mega.co.nz/#!5YNACDTJ!N0pIow27_Tfsx4dMfMq4HA11ZSlEt7L135HvYEOuBU8

perhaps you can swap in the relevant .exe files from the above into the /resources/software/ folder of MoneroX you can have a monero GUI on windows 64 that sips RAM like a fine wine?

AGAIN - don't trust these. Test them until you trust them. Make sure they do everything they should do. I tested them on the box I compiled on and another windows 7 box.

Hopefully someone will post the data.mdb download link. 

( removed the converter thing)

wow, no takers? I thought "the drooling masses" would be all over this.

I'd be more interested in the data file for syncing purposes although at 16gb, not sure who's willing to host.

Luckily, for whatever reason, the linux data.mdb works in windows, and the linux data.mdb shows up as ~6 gigs until the windows bitmonero accesses it, and then it turns into 16 gigs (due to what fluffypony called windows not liking sparse files). And then, magically, when either of them are compressed, they go to around 3.5 gigs or something.

Regardless, the best thing would be to sync from scratch, independent of how long it takes, because, you, decentralization nom nom nom.

Oh, it's still syncing on my end... at around 270k blockheight so about half way in about a week.

[5w00p]

So, as a Windows user, what is my guidance on getting the database version going on my computer?

I will be downloading the database blockchain in its entirety.

Thanks.

[GingerAle]

So, as a Windows user, what is my guidance on getting the database version going on my computer?

I will be downloading the database blockchain in its entirety.

Thanks.

You can compile on your own, or try my compiled binaries posted above. Then run bitmonerod.exe

This will get you everything but the blockchain data file. This file will be posted tonight via mega, and there's some monerian i've been trying to get it to that will also host. Or u can get the current database from getmonero.org and try the converter.

[oblox]

So, as a Windows user, what is my guidance on getting the database version going on my computer?

I will be downloading the database blockchain in its entirety.

Thanks.

Probably wait for someone trustworthy to upload the compressed data.mdb file, extract and drop into the lmdb data folder.

[smooth]

for an exchange like poloniex to create openalias for each user with theyr payment_id, for example, malmen.xmradd.poloniex.com, i can help to implement this

Part of the issue is exchanges having trouble integrating with their usual systems, workflow, and support. That creates a higher barrier to them even supporting the coin at all. Needing to incorporate DNS into that mix will make the problem worse.

It's a good idea for a value-added feature but not as a basic integration.

[smooth]

WARNING - these are not "official", as in, someone from the core dev team didn't compile them and gave them the a-ok. I'm putting them here for testing purposes. I compiled following the instructions on the github. Perhaps they are static? Perhaps you can run the LMDB version of bitmonerod on your win 64 box and only use 50 megs of ram?

https://mega.co.nz/#!5YNACDTJ!N0pIow27_Tfsx4dMfMq4HA11ZSlEt7L135HvYEOuBU8

perhaps you can swap in the relevant .exe files from the above into the /resources/software/ folder of MoneroX you can have a monero GUI on windows 64 that sips RAM like a fine wine?

AGAIN - don't trust these. Test them until you trust them. Make sure they do everything they should do. I tested them on the box I compiled on and another windows 7 box.

Hopefully someone will post the data.mdb download link. 

( removed the converter thing)

wow, no takers? I thought "the drooling masses" would be all over this.

I'd be more interested in the data file for syncing purposes although at 16gb, not sure who's willing to host.

If you compress it will get much smaller. There is only about 4 gb of actual data in there.

[MalMen]

for an exchange like poloniex to create openalias for each user with theyr payment_id, for example, malmen.xmradd.poloniex.com, i can help to implement this

Part of the issue is exchanges having trouble integrating with their usual systems, workflow, and support. That creates a higher barrier to them even supporting the coin at all. Needing to incorporate DNS into that mix will make the problem worse.

It's a good idea for a value-added feature but not as a basic integration.

Its worst because its diferent, but at the momment we already have apis working, i write this one by my own
https://github.com/MalMen/PHP-Monero

jebriggsy already forked my code and in my opinion is realy good and well commented
https://github.com/jebriggsy/PHP-Monero

Adding openalias on top of it will give some more work to exchanges but will bring cryptocurrency to another level of easy use to the final user, i dont buy people claiming that  "exchanges are not adding monero because the ticket system will be overflowing"

By the way, in my opinion another exchanges are not adding monero because they dont believe in monero or because they have interests in adding it

[smooth]

By the way, in my opinion another exchanges are not adding monero because they dont believe in monero or because they have interests in adding it

I have to definitely disagree with that when you have exchanges with huge numbers of coins (hundreds? certainly dozens) listed. They don't believe in all those coins at all, it is just that adding them and supporting doesn't have the same development, operational and support barriers that Monero has. Some of that (especially on the support side, but also integration) comes from payment IDs.

What you say is probably correct when it comes to exchanges that list a smaller number of coins such as bitfinex or btc-e. To get onto those exchanges we likely have to get bigger first.