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.
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:
- 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.
- 'account_key' RPC is used to get the destination key.
"account" : "nano_1e5aqegc1jb7qe964u4adzmcezyo6o146zb8hm6dft8tkp79za3sxwjym5rx_1234"
Node update: If suffix then append suffix, else return key like normal.
- Now 'block_create' RPC is used.
Node update: If suffix found in 'link' or 'destination' field then parse into new block field 'tx_id'.
"difficulty": "ffffffe1278b3dc6", // since V21.0
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
Ok I took some time this weekend and read up on Natrium code . 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.
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.
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
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.
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...
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".
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.
Great point, that encoding idea would be perfect to add. This would also apply to off-chain solutions as well.
For the state block design, in light of the new ES ideas and TPS time throttling etc. I think a lot of the old arguments against a payment id field are dated. What if we no longer need POW work field after update? Perfect time to use some of that real estate for this new field.
Im not against off-chain solutions, I think we should do both to add flexibility.
While it's true that the
work field may one day be removed, the goal really should be to reduce the storage size of a block. I believe reducing the block size by 8 bytes would be the preferential approach over keeping the block the same size and utilising the field as an ID/memo.
I'm not personally against the idea though, I do think it would make payment integrations much simpler than any of the other proposed solutions (including the handoff system).