Hi I am a cyrpto fan holder of ADA and a big believer in the future of blockchain technology. I recently made a payment in Monero to a Bittrex account and even through I was extremely careful it did not arrive. It was a considerable amount of money so this got me thinking that as it currently stands cryptocurrency in all its existing forms is nowhere near ready for mainstream adoption. For it to be able to be successful to needs to be as easy to use as tap and go contact less card technology or Internet banking.
This got me thinking about what I think would be a vitally important part of any transaction that currently is not even part of Internet banking system that would make crypto payments more widely accepted.
I am not sure if this is part of the Cardano system or if it is planned but what I thought was that if I wanted to make a payment to another one of my accounts or a 3rd party account then instead of just paying it I
-
could either declare that i intend to make a payment which would then be broadcast to the blockchain or a sidechain. Then if I accessed my other receiving account that declaration could be seen in that account confirming that I have indeed declared to pay the correct account. From here I could simply confirm the transaction and convert the declaration of intent to pay into a transaction fully knowing that it will arrive at its intended destination and not a different account by mistake.
-
if I wanted to pay a third party I could make a payment and at the time of payment a unique key is generated that could be shared with the 3rd party allowing them to receive the funds. If the shared key is not provided and verified then the third party cannot make a claim to those funds. If the claim is not made within a set time limit, Eg: 7 days then the payment would be automatically returned to the senders address.
With current existing online banking if you make a payment to 3rd party account and make a mistake you cannot recover those funds without a lot of trouble and time. By using the above method payment mistakes could be avoided completely. this would give the cyrptocurrency using these features an advantage over nearly every other payment system.
I am not sure if this is a new or old idea and I am sure these ideas and many others have been thrown around but I just through I would put it out there and see what some of the Cadano Dev’s might have to say about this.
3 Likes
I love this and would support any network that is willing to do it! Not a very difficult code on a 3rd gen blockchain i think, the packet leaving your wallet say’s it will return to sender if not opened with specific code - Brilliant!
I like both the options you shared - they would be well received by new users. But I do think we need to think along the lines of simplifying things rather than add additional layers of declaration/shared key.
For this particular scenario -
- If funds are not delivered to “any” valid wallets within XYZ days, can then be on a auto-return to sender rather than one way non-retrievable?
Thanks for your replies and glad this dialogue has been opened. I only used to program PHP and MYSQL may years ago. I am out of touch now but I can see your point. So the question is what are chances that if one of the CHARS changed in an address that this wallet would exist?
How would this help if you accidentally sent to the wrong wallet?
Unfortunately we all make mistakes and I am assuming that if somehow during a copy and paste that the wallet address was changed a little the chances that another wallet with the same addess existed would be slim but this still needs to be allowed for.
The general idea is that if you announced to the blockchain that you plan to make a payment then this information does not need to be verified it just needs to accept it as true. If the payment address is matched to an existing address then then that address holder should be able to see in their wallet that the sender is planning to send them tokens. This would be particularly useful when transferring funds between your own accounts. if you can see the planned payment and the amount matches the planned payment this would confirm you are sending to the correct wallet.
I understand any future system needs to be as light and fast as possible but at the same time I believe that great improvements can be made over existing banking systems
The other way to handle 3rd party payments would be to add a payment ID like Monero. So if the PAYMENT_ADDRESS == WALLET_ADDRESS && PAYMENT_ID == WALLET_UNIQUE_TRANSACTION_ID then the transaction would go straight through but if either of those statements where not true the transaction would be rejected and sent straight back to origin address. This way you could not possibly make a wrong payment. If you sent to the wrong wallet the unique transaction ID would be wrong. This does not even have to have an amount attached to it. It just has to have one unique ID per transaction.
This may not be the right way and I am sure there are other ways to do this so let me know what you think. Dev input on this topic would be great.
1 Like
Great post here and a key pain point for all crypto at the moment…send it to the wrong address and you are in deep, deep mud.
We just made AdaCheck.io as a small step for making it easy to verify/preview the destination address before sending, but that’s a small step vs the main features have to be in the blockchain code.
Now Ada is one step ahead of Ethereum in that Ada address have a CRC (cylic redundancy checksum) and thus avoid the many postings like this:
https://www.reddit.com/r/ethereum/comments/72el8i/have_i_lost_41_ether
Thus, for this idea -
The CRC aspect of all Ada addresses should not let it go to an invalid address. However, it doesn’t mean you can’t end up with a valid but wrong (not the one intended) address.
Having the human readable address and even possibly a photo of the user (though privacy issue) but regardless human readable will make it faster/easier once that is enabled.
Ultimately though PaulKovac’s main point is dead on - sending transactions has to be made as safe/easy and error free as possible to get to mainstream acceptance.
I think Ada already addresses this via the CRC checksum that is built in.
Example: this address is valid:
Ae2tdPwUPEZKmwoy3AU3cXb5Chnasj6mvVNxV1H11997q3VW5ihbSfQwGpm
(cut and paste into AdaCheck.io and you can verify).
Now change one letter - I changed the last one from m to n…and presto, verify and it’s flagged as an invalid address.
This is b/c it would be difficult to accidentally regen a new address with an appropriate checksum simply by randomly changing even multiple letters (I also tried randomly changing several just for kicks, it still fails out) .
So again I think in this case Ada is ahead of the curve with the CRC/checksum, but can still be improved.
yep great but it has to be quick.
that other idea I had is linking wallet address to a users ID on another blockchain so if you had a wallet address as soon as you added a payment address it would automatically look up that address and check to see if a users ID is attached to that address that was linked to it via the ID blockchain showing you that users name, or company name. This is not a fail safe but i would add a layer of validity to the transaction as you can instantly see who you are paying. People would have to decide themselves how much information they want to display to public. How these ID’s are verified is another thing. I think you could have a scoring system and the more verification checks that individual has gone through the higher the score. But this would be separate blockchain projects of course that could link to any cyrptocurrency transaction.
I see the reasoning behind adding further verfication to secure payment but I also see the additional hassel (sub-optimal experience) of adding more manual steps. If steps can be automated then perfect.
Like for reference in this case:
Scenario 1: Invalid address, auto-return
Correct Address: Ae2tdPwUPEZKmwoy3AU3cXb5Chnasj6mvVNxV1H11997q3VW5ihbSfQwGpm
Invalid Address: Ae2tdPwUPEZKmwoy3AU3cXb5Chnasj6mvVNxV1H11997q3VW5ihbSfQwGp(Z)
Scenario 2: Someone elses address
Correct Address: Ae2tdPwUPEZKmwoy3AU3cXb5Chnasj6mvVNxV1H11997q3VW5ihbSfQwGpm
Another Valid Address: Ae2tdPwUPEZKmwoy3AU3cXb5Chnasj6mvVNxV1H11997q3VW5ihbSfQwGp(X)
In scenario 2, I am not sure of the probability of Scenario 1 turning into Scenario 2. If the probability is high, then by all means should build further qualifiers into a transaction.
The big point around errors creeping through with the non-friendly addresses is still valid. I am hoping we could see a solution which wouldn’t require additional steps from an end user perspective.
That’s my non-techie 2 cents.
back to KISS (keep it simple stupid).
I agree sounds good to me