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

[Johnny Mnemonic]

Keep in mind the plan is to eventually serialize payment IDs into the address anyway.

This proposal is not to replace the current functionality, but to add optional new functionality for merchants to generate unique "receiving addresses" on the fly.

My philosophy is that it's not our place to dictate how these tools should be used, but instead to provide the functionality for the merchants and transactors to use them as they see fit.

[1714489704]

1714489704

[1714489704]

1714489704

[1714489704]

1714489704

[1714489704]

1714489704

[1714489704]

1714489704

[1714489704]

1714489704

[Johnny Mnemonic]

So I tend to agree that serializing the address + payment ID overcomplicates the issue. In the meantime, during these growing pains, I think the available wallets should be "dumbed down" to recognize that 90% of users are coming to Monero from Bitcoin, and the other 10% are the aliens that invented Cryptonote. And so the wallet should go "hey your sending money into the void, do you want to add a payment ID?"

GingerAle, if you owed me $50, payable by check, should it not be enough for you to simply write me a check for $50?

Is it reasonable for me to demand that you include a specific memo that, if forgotten, may result in the loss of your money?

[luigi1111]

A few counterpoints for discussion:

Instead it will make the address technically more complex (instead of 2 bits of information it would be storing potentially 3). Also one has to remember, if you introduce such feature you can pretty much never remove it.

Agree and agree, though I don't see either as real barriers. It is prudent to consider these.

From the technical side (of how payment ID is implemented) such solution would present user experience nightmares. Currently the payment ID is associated with the whole transaction, not the destination. If we had addresses which included the payment ID we would soon get users who would want to pay to several of those addresses, but since this is technically not possible we will forbid that.

This will always be the case. You can't associate a payment ID with destinations without rendering stealth addresses pointless. Payment IDs are fundamentally incompatible with the send-many function as far as I can see. However, I'm struggling to see the situation(s) where this would present an issue. If it's a merchant, the payment ID should be one time use and the "address" never used again. If it's an exchange where you're reusing the payment ID (or "address"), then you already know you can't use send-many. All these edge cases have to be accounted for in the code, but none of them seem intractable to me (so far).

Now if the user did not care about the payment ID in one of the addresses there would be no easy way to just throw the payment ID out of the address.

Completely disagree. It's a simple process to strip the payment ID and recalculate the checksum for a standard address instead; however, no (public) tools exist to do it yet. Going along with what I wrote above, though, I don't know of a situation where you would want or need to do so (that in no way means no such scenario exists).

The only “good” thing about the proposal is that the payment ID gets checksummed. But considering the amount of data users currently have to enter already, I don’t think it’s feasible to think that anyone does it by hand - thus the importance of checksum on that data diminishes.

I see this completely the other way. If people aren't currently checking their payment IDs, this should be wholly better. This should mean there would be no support requests for "mistyped payment ID" in addition to "forgot payment ID".

Lets think about how users can pay on a website.

• Using a mobile wallet. Entering the address manually is not an option. User friendly options for mobile is QR code. They can embed the payment ID in it without changing anything in the Monero address format. OpenAlias can be used as a fallback.
• Using a desktop wallet. In this case the desktop wallet should install some URI handler, which would allow the user to just click a link on the payment page which would open their wallet. Again, this URI can include the payment ID, thus no need for any changes in the Monero address format. OpenAlias can again be used as a fallback.
• Using a command line wallet. The website should just display the whole command for simplewallet users, which they can copy-paste into the terminal. But lets be honest nobody should expect non-technical Monero users to keep using simplewallet after a better alternative is out. Alternatively simplewallet could implement a new command to pay to payment URIs. That way users can “Copy link address” from web and paste it into simple wallet.

Mobile: agree you can put the payment ID there, but it's not really different or "better" than having it as part of the address (IMO).

Desktop/command line: this is just speaking for me, but I never do that URI stuff; rather I paste the address (and payment ID for XMR) and fill in the rest of the stuff manually (or type in case of command line). That's not an argument against them though.
Again, I don't see anything "wrong" with including an "integrated address" in a URI vs a "standard address" plus a "payment ID" in a URI. One has one less field, one has a more complicated address. I would argue neither mean much to nearly all users.

What responsible wallets could also do, to educate users about the “reference field” (payment IDs), is to prompt the user if they really want to leave the payment ID field empty. That way the users at least confirm that they know what they’re doing if they transfer money with an empty payment id.

Absolutely sensible.
Edit: or maybe not, as smooth points out.

2. Ratify and implement stealth payment IDs (much shorter), can be expressed in both serialised and non-serialised formats

Has any work or discussion been done on this? I'd love to read about it if it's logged somewhere.

[smooth]

The reason why someone suggested the idea was to “fix” the problem of Bitcoin users not paying attention to the payment ID field and making deposits the recipient cannot match, if I remember correctly. (Didn’t find the original post or the source of the idea, so it might not be correct.)

That was only part of the reason. The other reason is that the crypto ecosystem generally operates on the concept of address = destination. In addition to the use case of exchanges, payment processors generate an address for an invoice. When you pay to that address, the payment is applied to the invoice.

Payment IDs exist in cryptonote because of the cost of scanning for stealth address payments. Separating the destination into two parts ("address" and "payment ID") is simply an optimization to allow faster scanning of a large group of destinations, but that really isn't something that users need to be concerned with. (Payment IDs weren't even part of the original design, but were added later, after the Bytecoin "reveal" i.e. launch, most likely when their exchange identified the problem by trying to actually process payments without it.)

What responsible wallets could also do, to educate users about the “reference field” (payment IDs), is to prompt the user if they really want to leave the payment ID field empty. That way the users at least confirm that they know what they’re doing if they transfer money with an empty payment id.

I disagree. I don't want to be bugged when I make ordinary payments. I rarely use exchanges and there are no (?) payment processors in the Monero space. Payment ID, blank or otherwise, is almost completely uninteresting to me, and I don't want to be prompted to enter one.

Serialized and stealth payment IDs are already on the development goals document and have been for several months. It's something that is going to happen. The only real questions revolve around how to implement it. Once it is implemented there is little doubt it will be adopted by payees because of the vastly reduced support costs associated with explaining the separate payment ID concept to users who don't really care about it, and dealing with failures when that doesn't happen properly.

Stealth payment IDs are fine, and good for the case where payment IDs aren't assigned in a proper one-time use manner (the same issue solved by regular stealth addresses preventing Bitcoin's rampant, but in-theory unnecessary, address reuse). And indeed they can be encoded smaller (hex is dumb compared to base 58). But even if they are little shorter, Monero addresses(+pid) will still be extremely long (too long to memorize, and too long to be a drop-in replacement for BTC addresses), so I don't see much of a benefit there from the shorter length itself, in practice.

we would soon get users who would want to pay to several of those addresses, but since this is technically not possible we will forbid that

This is an artifact of the how payment IDs were tacked onto the system at the last minute (after release in fact). There is no reason why a payment ID shouldn't be (optionally) attached to each destination, not the transaction itself. Failing that, any wallet presented with an attempt to send to multiple payment IDs can break up the transaction, just as they do now for transactions that are too large.

[GingerAle]

hrm, I seem to have lost myself here. Are we talking about 3 different things?

1. Serialized addresses + payment IDs
2. Stealth payment IDs
3. User-end payment ID prompts

I disagree. I don't want to be bugged when I make ordinary payments. I rarely use exchanges and there are no (?) payment processors in the Monero space. Payment ID, blank or otherwise, is almost complete uninteresting to me, and I don't want to be prompted to enter one.

Yeah, i've heard this argument before and I think a solution is to make another wallet available. Noob wallet. Designed for bitcoiners coming to Monero.

Serialized payment IDs are already on the development goals document and have been for several months. It's something that is going to happen. The only real questions revolve around how to implement it.

The other real question is when. Don't get me wrong, i'm all for making Monero better and more awesome, but IMO there's no reason not to create something in the interim. If the when is another year, thats another year of users sending money to an exchanges address void, etc. Granted, this goes against the philosophy implemented for the database effort, in that if Monero Core devs had opted instead to use the glorified scratchpad thing, there would be less urgency for database development.

edited

[GingerAle]

though I think we just found the topic of the next missive.

[forevernoob]

So I have been out of the crypto world for a week or so and now all of a sudden Poloniex has sold out to the goverment.
I still would like to trade but don't wanna bother with the KYC bullshit.

Is there any alternatives you guys recommend? I have tried Bittrex but the volume is very low compared to Poloniex.

[Lloydimiller4]

Yesterday marks my one year anniversary as a Monero holder
It started a speculative position from a tip a close friend gave me, and it has grown to become my only holding in crypto. Call me crazy, but I am a big believer and in it for the long haul.

[smooth]

hrm, I seem to have lost myself here. Are we talking about 3 different things?

1. Serialized addresses + payment IDs
2. Stealth payment IDs
3. User-end payment ID prompts

I disagree. I don't want to be bugged when I make ordinary payments. I rarely use exchanges and there are no (?) payment processors in the Monero space. Payment ID, blank or otherwise, is almost complete uninteresting to me, and I don't want to be prompted to enter one.

Yeah, i've heard this argument before and I think a solution is to make another wallet available. Noob wallet. Designed for bitcoiners coming to Monero.

Sure, if there were actually a good reason to keep payment IDs separate. Payment IDs are fundamentally an optimization that happens to be useful to the inner workings (and in particular one that was apparently added last minute with little to no thought behind it), not something that end users need to be explicitly aware of, especially not noob users. (But see below.)

Serialized payment IDs are already on the development goals document and have been for several months. It's something that is going to happen. The only real questions revolve around how to implement it.

The other real question is when. Don't get me wrong, i'm all for making Monero better and more awesome, but IMO there's no reason not to create something in the interim. If the when is another year, thats another year of users sending money to an exchanges address void, etc. Granted, this goes against the philosophy implemented for the database effort, in that if Monero Core devs had opted instead to use the glorified scratchpad thing, there would be less urgency for database development.

Agree completely, in the sense that easier short term measures to address a problem are fine, as long as it isn't a lot of work and doesn't get in the way of other development plans.

I don't see a problem with a pull request that adds a no-pid warning to simplewallet for example, especially if it includes a config option to disable it. The developers of other wallets will do what they want, but simplewallet being the reference can and does lead by example.

[Johnny Mnemonic]

Yeah, i've heard this argument before and I think a solution is to make another wallet available. Noob wallet. Designed for bitcoiners coming to Monero.

Again, I don't see why that's necessary. All wallets should be "noob wallets" because payment ID should not be the concern of the sender. Give me an address to send coins to. That's it. Any additional step is unnecessary.

[wpalczynski]

Preparing for tonight's meetup in Brussels, Belgium.


Step 4: ride in the smallest elevator ever (seriously, you can just barely fit two people sideways):

...

Its not the elevator, its you. Fatso.  You look cheap, I'm not surprised.

Better a cheap look, than being stupid Improving the look is easy...

You're correct. Only retards take stupid-looking selfies and post them on the official thread hours before a conference. Who's going to take him seriously ?!

I think the pictures are cool.  Wish I could get out more.

[GingerAle]

Yeah, i've heard this argument before and I think a solution is to make another wallet available. Noob wallet. Designed for bitcoiners coming to Monero.

Again, I don't see why that's necessary. All wallets should be "noob wallets" because payment ID should not be the concern of the sender. Give me an address to send coins to. That's it. Any additional step is unnecessary.

right, i get it, and it seems we are definitely moving towards that in some fashion (serialized addresses / payment IDs), if we're on the same page.

in the meantime, though, i would argue that a stop gap solution is warranted. I don't know if you're lurking on IRC, but almost all of the folks that drop in (i.e., are there for one purpose and then leave) ask about the payment ID. i mean, i'm generalizing, but its a lot.

[wpalczynski]

You're correct. Only retards take stupid-looking selfies and post them on the official thread hours before a conference. Who's going to take him seriously ?!

I'm having fun and enjoying myself, you should try it sometime:)

PS. Wrote you a limerick:

There once was a troll known as Primer
Whose insults were simply to-die-fer
It's a snap being mean
When you're behind a screen
And in mom's basement you're a resider

A view from mom's basement : http://imgur.com/i2Vy6LU

Monero is not going anywhere with you at the helm... I can tell a loser from afar.

Dude you shouldnt talk with that big dildo on your desk.

LMAO

[wpalczynski]

Did you guys here? I'm a DEV NOW! I've been anointed the title of Monero Dev by the community:

Monero's dev to do list this year ~ FluffyPony, GingerAle and Smooth

1. Changing our copied GUI wallet color from RED to BLUE.
2. Create once or twice a week a thread about EVAN even though we have starting problems just like every other coin did.
3. We Cry"p"to about it in forums.
4. Wait for another coin like Byte to coin from or actually for Byte to do something new and we change colors maybe?
5. THIS IS IMPORTANT let's all pray that monero investors don't get mad at us and ask for a newer team to actually do some work.
6. Hope their investors don't do what OTOH did and moving on with DASH.

BOW BEFORE MY AWESOME DEVNESS.

It doesn't take much to move up in this cryptoworld, does it?

ROTFLMFAO!

Beauty of open source is we are all developers. 
 
If someone understands cryptography and can code, they are welcome to jump in and prove themselves.  Hell, the devs even maintain an open irc channel. 
 
But this is the kick ass desert island we have all woken up on, and not everyone is a carpenter.  Some of us are hunters, and some are fisherman.  Point is, everyone can contribute to the island, and there's a lot of jobs and roles on the road to making it a success. 

I guess Primer got the job of village idiot on our island.  No wonder he is so bitter.

[Johnny Mnemonic]

Yeah, i've heard this argument before and I think a solution is to make another wallet available. Noob wallet. Designed for bitcoiners coming to Monero.

Again, I don't see why that's necessary. All wallets should be "noob wallets" because payment ID should not be the concern of the sender. Give me an address to send coins to. That's it. Any additional step is unnecessary.

right, i get it, and it seems we are definitely moving towards that in some fashion (serialized addresses / payment IDs), if we're on the same page.

in the meantime, though, i would argue that a stop gap solution is warranted. I don't know if you're lurking on IRC, but almost all of the folks that drop in (i.e., are there for one purpose and then leave) ask about the payment ID. i mean, i'm generalizing, but its a lot.

I proposed (and luigi1111 designed) a stop-gap solution that I believe would work great, and should be fairly simple to implement. It's just a matter of somebody doing it (luigi said he might).

[GingerAle]

Yeah, i've heard this argument before and I think a solution is to make another wallet available. Noob wallet. Designed for bitcoiners coming to Monero.

Again, I don't see why that's necessary. All wallets should be "noob wallets" because payment ID should not be the concern of the sender. Give me an address to send coins to. That's it. Any additional step is unnecessary.

right, i get it, and it seems we are definitely moving towards that in some fashion (serialized addresses / payment IDs), if we're on the same page.

in the meantime, though, i would argue that a stop gap solution is warranted. I don't know if you're lurking on IRC, but almost all of the folks that drop in (i.e., are there for one purpose and then leave) ask about the payment ID. i mean, i'm generalizing, but its a lot.

I proposed (and luigi1111 designed) a stop-gap solution that I believe would work great, and should be fairly simple to implement. It's just a matter of somebody doing it (luigi said he might).

well marvelous. Sorry I guess I didn't fully understand it.

[smooth]

Yeah, i've heard this argument before and I think a solution is to make another wallet available. Noob wallet. Designed for bitcoiners coming to Monero.

Again, I don't see why that's necessary. All wallets should be "noob wallets" because payment ID should not be the concern of the sender. Give me an address to send coins to. That's it. Any additional step is unnecessary.

right, i get it, and it seems we are definitely moving towards that in some fashion (serialized addresses / payment IDs), if we're on the same page.

in the meantime, though, i would argue that a stop gap solution is warranted. I don't know if you're lurking on IRC, but almost all of the folks that drop in (i.e., are there for one purpose and then leave) ask about the payment ID. i mean, i'm generalizing, but its a lot.

That's exactly why you're both right.

[kazuki49]

So I have been out of the crypto world for a week or so and now all of a sudden Poloniex has sold out to the goverment.
I still would like to trade but don't wanna bother with the KYC bullshit.

Is there any alternatives you guys recommend? I have tried Bittrex but the volume is very low compared to Poloniex.

I said some days before SHTF that we should look back at Bter as alternative, I was already using Bittrex so I guess I'll be fine.

If cryptsy or other exchange could implement XMR right now it would be optimal for them (and us).

[cAPSLOCK]

So I have been out of the crypto world for a week or so and now all of a sudden Poloniex has sold out to the goverment.
I still would like to trade but don't wanna bother with the KYC bullshit.

Is there any alternatives you guys recommend? I have tried Bittrex but the volume is very low compared to Poloniex.

I said some days before SHTF that we should look back at Bter as alternative, I was already using Bittrex so I guess I'll be fine.

If cryptsy or other exchange could implement XMR right now it would be optimal for them (and us).

I think BTC-e would be my choice.

[coinfusion]

Update!!

Well I lost it all. My hard died on me. I was able to sync with bitmonerod (thanks for the help by the way). However, my .keys files went down with the hard drive... 534 Monero's!! almost a year worth of mining down the drain.

Well, i still have 1.5 KH/s worth of mining power. Back to the drawing board....

Word of caution to all - BACKUP/SAVE your stuff! Don't be me!!!

Sorry to hear that.

Just wanna give the following tip.

Depending on the drive, and if it is a mechanical problem, SOMETIMES turning the drive upside down gives you enough access time to get some files out.

I also read that getting it really cold (freezer) and then copying files quickly works for some people.  Sounds crazy but might be worth a try.  If monero ever gains a lot of value paying 2-3k for recovery will be a non issue.

You have to be careful about drive feezing, because if you go too cold, or run the drive for too long at cold then the spindle bearings will be destroyed. The bearings may damage the platter surfaces if they emit any particles or gelled lubricant while running cold, which would dramatically decrease the chances of data recovery by any paid service.