Unique payment ID via payment protocol

That's where you're wrong. It's not of relevance to only two parties in a lot of circumstances, it's of relevance to the whole network. The memo field is an immutable piece of data that has been verified by the Nano network as being owned by those parties. That's a powerful thing in itself, it unlocks use cases that we otherwise do not have (for example, IOT commands, basic scripts, second layers, etc). The trade-offs are clearly worth it in this case if the goal is to get adoption.

This thread is about payment ID and for that only (up to) 2 parties are interested in tracking payments. The rest of the world doesn't care.

Why is this more credible than signing a message with a private key?
Why does the message have to be stored in the NANO ledger?

I don't disagree.
But none of these use cases is related to value transfer and that's the primary goal of NANO: doing value transfer as efficiently as possible.
If you integrate functions, that don't support efficient value transfer, you take away efficiency.

I can understand that you perceive it this way, but I respectfully disagree.
It pretty much sounds like you are advocating for a short-term boost of adoption, while being willing to endanger the long-term adoption of NANO as the most efficient protocol for globally available, decentralized, peer-to-peer transfer of value.

3 Likes

I can promise you that the world isn't going to adopt Nano unless it expands its featureset. The future of digital money can do more than just move 1 unit of account to another person. Bitcoin has/had the right idea by sacrificing a small amount of "performance" or "efficiency" for expanded use-cases, and now that they have Lightning Network as well, there's not much reason to use Nano aside from it being more decentralized (which most people only care about to a small degree and tend to settle for "some decentralization is good enough", hence Solana's rise to fame). All of the UI complexities of LN are fading away now, and once everyone is on it, painpoints of onboarding won't even matter. If the core devs don't believe that the Nano core should handle more than the "1 coin go from here to there" use case, that's fine, but at least allow other people to build on top of Nano and expand it to do useful things. Otherwise it's just going to get left in the dust to the myriad of flexible competitors populating the space. That's if it can even outcompete Bitcoin, which is probably unlikely given the above, unless something changes.

I think the market has been and is speaking very loudly that this small niche is not enough. The technology is near-perfect for what it -can- do, but obviously it's not enough or the market would have made moves into Nano by now. The fact that it's been treading water for so many years and never seems to catch a break is something people need to stop ignoring. If you make something that people see value in, they will buy it. Obviously not enough people see value in what Nano currently offers, or we wouldn't be on the second page of coinmarketcap, and continuing to fall lower like it has been for ages. The only reasons I hear for the lack of adoption or interest are conspiracies, but it's far more likely that it just isn't offering what people want.

Just take a step back and ask yourself, why are projects like Solana exploding, but projects like Nano not?

  • Solana has fees (small ones) - small fees are evidently good enough for most people. Being feeless has some nice UI advantages, but it's not a deal breaker if the fees are low enough.
  • Solana is highly scalable and fast - so is Nano.
  • Solana supports other use-cases other than value transfer

That's really it. You can't say it's awareness because basically everyone in crypto has heard of Nano by now given the thorough Twitter and Reddit marketing that happens. As you can see, there's only one missing ingredient that separates the two. You can make these comparisons with most of the coins that are seeing success and boil it down to the same thing.

I think most people in the crypto space overestimate the scope that crypto(currencies) can/should address. Software and second layer protocols have a near endless possible feature set. The question is what benefits from being on a decentralized, trustless, permissionless network. And the answer is usually a lot less than people think.

Nano can be integrated with all kinds of off-chain protocols to expand its utility. And in fact I think a key area of work to promote adoption will be the establishment of some of these off-chain standards, so that businesses have a clear and frictionless path to integration. Ideally this could be something that the foundation works on either in parallel with the network protocol or after the network protocol is "finished," since having a centralized authority promote such standards will greatly expedite their implementation by third parties.

But what we're discussing here is what needs to be on the network, and pointing to use cases that don't fundamentally need to be decentralized/trustless/permissionless because they might make integration more convenient is not a good long-term strategy. The vision of Nano is a globally scalable currency protocol, and the adoption of cryptocurrency as a whole is simply not at the scale where those long-term decisions are paying off yet. (Well, except for the network fees for the two biggest ones.)

The market for speculation has been speaking loudly. The market for adoption, where the true competition is, has barely begun.

I think it's hard to ignore price action because it's shiny and easily quantified, but ultimately that's what you have to do because the price action is largely meaningless.

If you make something businesses see value in, they will adopt it.

But has everyone in business heard of it? Certainly not. That's who needs to hear about it for adoption.

4 Likes

Maybe I'm missing something but how is wallet support needed for the suffix idea? I've played with a docker test node locally but I don't run a full node. Here is flow I'm thinking:

  1. Wallet providers accept destination account as normal with new suffix id '1234'. I admit this might require adjusting field length but that would be a small patch.
  2. 'account_key' RPC is used to get the destination key.
    Request:
{
  "action": "account_key",
  "account" : "nano_1e5aqegc1jb7qe964u4adzmcezyo6o146zb8hm6dft8tkp79za3sxwjym5rx_1234"
}

Node update: If suffix then append suffix, else return key like normal.
Response:

{
  "key": "3068BB1CA04525BB0E416C485FE6A67FD52540227D267CC8B6E8DA958A7FA039_1234"
}
  1. Now 'block_create' RPC is used.
    Request:
{
  "action": "block_create",
  "json_block": "true",
  "type": "state",
  "balance": "1000000000000000000000",
  "key": "0000000000000000000000000000000000000000000000000000000000000002",
  "representative": "nano_1hza3f7wiiqa7ig3jczyxj5yo86yegcmqk3criaz838j91sxcckpfhbhhra1",
  "link": "3068BB1CA04525BB0E416C485FE6A67FD52540227D267CC8B6E8DA958A7FA039_1234",
  "previous": "F47B23107E5F34B2CE06F562B5C435DF72A533251CB414C51B2B62A8F63A00E4"
}

Node update: If suffix found in 'link' or 'destination' field then parse into new block field 'tx_id'.
Response:

{
  "hash": "FF0144381CFF0B2C079A115E7ADA7E96F43FD219446E7524C48D1CC9900C4F17",
  "difficulty": "ffffffe1278b3dc6", // since V21.0
  "block": {
    "type": "state",
    "account": "nano_3qgmh14nwztqw4wmcdzy4xpqeejey68chx6nciczwn9abji7ihhum9qtpmdr",
    "previous": "F47B23107E5F34B2CE06F562B5C435DF72A533251CB414C51B2B62A8F63A00E4",
    "representative": "nano_1hza3f7wiiqa7ig3jczyxj5yo86yegcmqk3criaz838j91sxcckpfhbhhra1",
    "balance": "1000000000000000000000",
    "link": "3068BB1CA04525BB0E416C485FE6A67FD52540227D267CC8B6E8DA958A7FA039",
    "link_as_account": "nano_1e5aqegc1jb7qe964u4adzmcezyo6o146zb8hm6dft8tkp79za3sxwjym5rx",
    "tx_id": "1234",
    "signature": "3BFBA64A775550E6D49DF1EB8EEC2136DCD74F090E2ED658FBD9E80F17CB1C9F9F7BDE2B93D95558EC2F277FFF15FD11E6E2162A1714731B743D1E941FA4560A",
    "work": "cab7404f0b5449d0"
  }
}

Given this flow only two node RPC calls need to be updated. Perhaps someone who knows more about wallet flows can chime in.

@Dwarfdeaths well said. Crypto is 1990s right now and it remains to be seen who will be standing in 2000s :wink:

Ok I took some time this weekend and read up on Natrium code :laughing:. I understand now they locally sign a block first and then send RPC 'process' request to their node.

So yes the 4 byte suffix idea would require wallet updates. A small setback considering the ongoing proposal to add other new state block fields.

My UX dream for Nano is to verify payments with a single api call without running a node. A 4 byte memo is the most direct way to achieve that. The second closest would be block hash handoff.

1 Like

I can't get past the 4 character suffix + 4 byte block field idea. I gave my best attempt at an alternate off chain idea but it would still be way more work for wallet providers to implement.

The suffix idea would be a simple variable pass through code update. The field could even be removed later on once an off chain protocol is firmly established.

I mean...

you want something like this

What it does:
-> you bind unique payment callback urls for each of your sales orders during checkout to an amount to receive
-> the server will give you a payment wallet address back (full "nano:" url with amount and stuff)
-> the user will pay to that address
-> server will notify you on that callback url
-> you ping the server to check the wallet status
-> you change the order status to paid on your e-commerce
-> you tell the server to release that temporary wallet
-> the server will settle the amount to your main wallet

There's an address pool so you don't contribute to the long term bloat of empty wallets

1 Like

Thats just a tool to make account pooling method easier. I would then have to host that code + a node + a callback endpoint. No way that Carol selling paintings on Etsy is going to do that.

I think there needs to be a paradigm shift. Originally Nano was designed to have as many nodes as possible (for max decentralizatoin), with one node for every merchant. Now we know that will never scale and thats why we have limited PRs and bandwidth caps etc. Merchants need to be able to do business without running a node. The shift in thinking needs to make life super easy for merchants (both online and in person). Without lots of merchants, no significant amount of commerce will ever happen in Nano. We need to think about Carol.

Why put all that stuff into the node instead of a wallet?
The user doesn't have to setup any of that Point Of Sale stuff if they use a software that already has it.
Make a wallet, it has nothing to do with the money transferring protocol.

Let's say you have a wallet:
User pushes the "new payment slip" button.
App generates a sequential number, user might input a label of sorts and an amount of nano. Then the app has this payment slip and a new address (you send that payment url to your customer).
Once the app detects the pending value it will generate the receive block, then check if amount is larger than the payment slip amount.
Once that's the case the payment slip will be marked as PAID and the funds will be sent to your main address.

That's it, that's all your WALLET needs to do and it has nothing to with the network.

1 Like

That works fine for in person transactions. What about automating online? Carol doesn't want to manually create invoices for every Etsy sale.

Then we create a plugin for a gateway like the one I showed, carol goes to etsy plugin marketplace and clicks install...

I'm writing one for woocommerce, by the way...

EDIT:
The code I showed you only works for a single merchant, but I have another private repository that works as a gateway for anyone

Not saying that won't work, I think it can be way simpler and more flexible (my main points on this thread so far). Check this out:

With the 4 byte payment ID look how slick this could be. 'Confirm payment' button logic is very easy to implement. All it has to do is make 1 API call to nano crawler (or any other explorer) and check for id '1234'. No running nano nodes or hosting (and trusting) other wallet add on software just to confirm a unique payment.

you had to generate the id anyways and check for it, it's the same as making a new address

Automating and handling the creation of new nano accounts in a secure manor is way more complex than generating a 4 digit client side id. Also 4 byte suffix method is one transaction for Nano network to confirm compared to the two transactions to send to new account then main account with pooling method. Network has to do double confirmations and store double blocks with account pooling. Thats worse than adding an optional 4 byte field imo.

This discussion is starting to lose structure so here are a few clarifications.

The UX we're focusing on is primarily user followed by implementors. If these two are in conflict we choose better user experience at the expense of implementors needing to do a bit more work.

Changing block data or the address format are just about the hardest things to do. There's no such thing as "just update the software to add a 4 byte field and remove it when you don't need it".

1 Like

Thanks for the clarification Colin I agree UX is king. Implementors and merchants are a very close second and essential for ecosystem growth.

Basically for all the payment id solutions, the UX is the same. User scans a QR code - done. User copy/pastes an address and amount field - done.

The major gains are for implementors and I don't think they should be ignored.

Also from what I've read, the state block fields will have to be updated anyway in V24 for the election scheduler. If an epoch update is required anyway lets make the most of it.

An optional 4 byte field would be a huge win for implementors (who eventually grow into mature businesses that host nodes and ultimately grow the ecosystem).

I do think the idea of integrating a payment ID into an address is the best way, assuming we decide to go down the route of attaching an ID field to the block. It's certainly not a bad idea, though the goal here is to reduce the amount of on-chain data necessary.

I do think if this were to be done, a better encoding scheme should be used, seamlessly encoding it within the address and also including it as part of the checksum calculations. We wouldn't want users to mistakenly remove the transaction ID component and continue to send a block. For instance, a user's wallet may not support the encoded address feature, so they simply remove the suffix to "fix" it. While the transaction goes through, the payment ID is no longer attached, and would be invalid. I would consider Monero's implementation to be a good example.

A minor nitpick, but transaction ID's also don't really fit in a 'state' block, as they don't form a part of the account state, and wouldn't be utilised within receive/change blocks. That being said, the current work field also currently breaks this rule somewhat, though it is used for all block subtypes.