Is there anything wrong using disposable addresses (single-use payment links)?

[nanoist]

Hi there,

I'm just wondering if there is anything wrong creating hundreds of disposable addresses (for unique payment links) ?

Would this prejudice the network performance?
Be harmful in regard of energy consumption?
Have any other negative impact?
Or does nano scales up flawlessly?

I'm aware that unique payment links do not equal a true shop implementation, using a unique address to collect the payments, but they allow in counterpart easier implementation and a faster way to add nano as a possible payment option. In very few hours, one can generate hundreds of payments links and copy them into a database column. Coding a true shop requires more time. Hence the question.

Thanks.

[davidscubadiver]

Nothing wrong with doing so if you find it useful. Just keep in mind that if you’ve got a lot of small accounts you will need to deal with a lot of small accounts!

[nanoist]

Thank you David.

The idea would be collecting the payment and know which product was purchased thanks to a 1-to-1 "product - nano-address" relationship.
Then, "manually" send the amount from the disposable address (aka account) that collected the payment to a main seller's address that consolidates all its sales, and then delete the disposable account.

One question I have is how can one easily automate the check of all accounts, as batch, typically on a daily basis, to know if a sale occured (i.e. if the account's balance is >0).

A second question is : Is there is a way to easily way, preferably self-hosted, to generate more than twenty accounts? I'm working on desktop and don't want to install an app on my phone.
NanoVault / Nault are limited to 20 accounts per wallet. I ignore if there is any protocol-related or other reason for that, but using several wallets to go beyond this 20-accounts limit would be complicated.

[jay]

There is nothing wrong, from the stand point, how things in nano work currently. It's actualy currently the only consistent way to identify payments (every order payment on separate address, and then consolidate nano to central account).

But viewed from potential future, it is ledger bloating.

For such a payment you need :

• Merchant creates new address ( open transaction )
• User pays to the new address ( send transaction + recieve transaction )
• Merchant transfers sum to from new address to his main account ( send transaction + recieve transaction )

Those new one-time-use adresses can not be pruned.

That is why, there are multiple ideas, how to change it, each has it's own downsides.

New state block design

As we continue to develop the protocol and the node implementation, we are constantly discovering opportunities for improvement. Some improvements would be very welcome on the network, but aren't possible or as effective with the current state block structure. Because of this, the introduction of a new state block version with structural changes is becoming a priority. This topic is aiming to discuss the changes we are considering and why we think they are worth the effort. Before formalizing t…

[nanoist]

@jay

It's actualy currently the only consistent way to identify payments (every order payment on separate address, and then consolidate nano to central account).

@jay

But viewed from potential future, it is ledger bloating.

Thank you, Jay.

In the integration guide, https://docs.nano.org/integration-guides/the-basics/ , there is an example telling how to "Send to an address with amount, label and message" :
nano:nano_3wm37qz19zhei7nzscjcopbrbnnachs4p1gnwo5oroi3qonw6inwgoeuufdp?amount=10&label=Developers%20Fund&message=Donate%20Now

Should one understand that it makes already possible to receive payments to a unique address, use a unique product identifier as value for the "label" field, and possibly use the "message" field to communicate the delivery address (although I assume the later would mean a privacy concern) ?

Are these guidelines for future implementations of the node ?

As not involved in the node developement, it is difficult to grasp what is working and what is at the project stage.

Thanks.

[jay]

@nanoist

example telling how to "Send to an address with amount, label and message" :

That is QR/URI code creation.
What to display user in wallet, where is he paying. Maybe wallet will save the message in local walet history.

But there is no 'message' in outgoing block, so merchant will not get the message.

[zach-atx]

See the Unique payment ID via payment protocol thread for some updates on an alternative approach to having the ID as a new field in the block.

[My1]

@nanoist

Have any other negative impact?

well pruning.
the most obvious level of pruning can ax any blocks that arent frontier leading to only one block per account. that tho creates an issue where many accounts mean more database bloat even on pruned nodes.

if these accounts can be emptied there could be some more sophisticated pruning that doesnt need to store the entire account state but only the things that do matter like the last block hash and the address. the rep doesnt matter as there is no balance and the balance doesnt need to be recorded when all entries in that subtable are zero. however you cannot prune these entirely off, which can be an issue long term.