-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
address update proposal #123
base: master
Are you sure you want to change the base?
Conversation
I would vote to either wait for other options or take some time. I don't like that flags use the first bits of addresses and users don't have a single address option with which they could define their transactions in any service without buying a domain (although the rules for displaying domain instead of address are not defined).
Probably still add explorers? |
Suggested behaviour: |
UQBtIj4QE6xT2gmUtfmT5xp9CDVOvCuIcj2w3bvRsZT_55Rk |
up |
I agree with @mr-tron that TON.DNS support should be a requirement for all TON services. Also I suggest rewriting a bit this TEP to put the migration plan up front and all the technical discussion below. Plus, let's add some realistic deadline and prepare network-wide communication to make all the users familiar with the change, so they are not surprised when the addresses switch from |
we are already working on supporting dns as first class address form. tongo library implemented it today. ton-kotlin promised to do it in the nearest future. tonutils-go author promised to think how it can be done. I hope over libraries developers will join to our small initiative. You can contact me in telegram @subden for any questions. |
Alright
…On Tue, Jun 13, 2023 at 1:05 PM Beybut Abdulragimov < ***@***.***> wrote:
Suggested behaviour:
0. All libraries, services and wallets should support DNS. tolya.ton
should be first class entity with same support level as
EQCdqXGvONLwOr3zCNX5FjapflorB6ZsOdcdfLrjsDLt3Fy9.
up
—
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A73LUSVVLRI4TRD6S4ERLJTXLCMVFANCNFSM6AAAAAAZEZCSKA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Okay I will contact you shortly
…On Mon, Sep 4, 2023 at 11:42 AM Denis Subbotin ***@***.***> wrote:
we are already working on supporting dns as first class address form.
tongo library implemented it today. ton-kotlin promised to do it in the
nearest future. tonutils-go author promised to think how it can be done. I
hope over libraries developers will join to our small initiative. You can
contact me in telegram @subden for any questions.
—
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A73LUSX7LKHG54QOF6XDTA3XYXZFDANCNFSM6AAAAAAZEZCSKA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Hello!
@tolya-yanot could you please elaborate on what's wrong with accepting the url-unsafe format of the address (just for backward-compatibility purposes)? |
…
There must be a mistake here. Shouldn't it be:
? |
How can i.merge ..? |
UQBM8_B71xv91aBGx7qSdauVyU0SqlrMQ9Ctd7b2XJ9eUS0G |
1 similar comment
UQBM8_B71xv91aBGx7qSdauVyU0SqlrMQ9Ctd7b2XJ9eUS0G |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Poer168
New address |
Hi is this true without knowing the account of a large amount of Coins and Tons Coins were withdrawn from notcoin the Tonkiper wallet |
Hi is this true without knowing the account of a large amount of Loton Coins and Tons Coins were withdrawn from the Tonkiparm wallet Hi, is it true to withdraw a large amount of Knotcoin and Toon Coin from the Toonkiparm wallet without knowing the account? UQC6P_IPXqi0fVw2F7uknJIBRgVVyCHzxa88lddDSS1iw2S- |
Ymb1104202
…---------- Forwarded message ---------
فرستنده: Rohan1363m ***@***.***>
Date: سهشنبه ۱۶ ژوئیه ۲۰۲۴، ۵:۴۳
Subject: Re: [ton-blockchain/TEPs] address update proposal (PR #123)
To: ton-blockchain/TEPs ***@***.***>
Cc: Yosofmb ***@***.***>, Manual <
***@***.***>
Hi is this true without knowing the account of a large amount of Loton
Coins and Tons Coins were withdrawn from the Tonkiparm wallet Hi, is it
true to withdraw a large amount of Knotcoin and Toon Coin from the
Toonkiparm wallet without knowing the account?
—
Reply to this email directly, view it on GitHub
<#123 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJRX4GJH6P7LN4RBEJJA6E3ZMR6VPAVCNFSM6AAAAAAZEZCSKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRZHA3DSNZTGY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I have updated it, but there is no news about Coinham and Ton-Coinham |
I didn't send any currency to anyone, I don't even know what happened to my tokens. |
Hi is this true without knowing the account of }xa88lddDSS1iw2S- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EQD5mxRgCuRNLxKxeOjG6r14iSroLF5FtomPnet-sgP5xNJb
👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alex UQC2RRBsgX-BPlrJjJgX2ZObVUlY0e67Fl0JGszCc5DcxBBT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alex
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
5) If destination is not `unitialized` then wallet app uses the bounceable/non-bounceable flag from the address representation for the `bounce` field of sending message. | ||
The wallet app checks the destination address - if it has an `uninitialized` state, then it sends a non-bounceable message, otherwise it sends a bounceable message. | ||
|
||
## Public keys |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
text/0002-address.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
S5GBV4VFFSVSW6VVFYBEAEVTNYCM6ZVP
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cap_method_seqno#5371 = SmcCapability;
cap_method_pubkey#71f4 = SmcCapability;
cap_is_wallet#2177 = SmcCapability;
cap_name#ff name:Text = SmcCapability;
cap_list_nil$0 = SmcCapList;
cap_list_next$1 head:SmcCapability tail:SmcCapList = SmcCapList;
dns_smc_address#9fd3 smc_addr:MsgAddressInt flags:(## 8) { flags <= 1 }
cap_list:flags . 0?SmcCapList = DNSRecord;
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0xF1CA31083E0c073779C8D5ACA3F1bB3b4CBB558B
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0002-address.md
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cap_method_seqno#5371 = SmcCapability;
cap_method_pubkey#71f4 = SmcCapability;
cap_is_wallet#2177 = SmcCapability;
cap_name#ff name:Text = SmcCapability;
cap_list_nil$0 = SmcCapList;
cap_list_next$1 head:SmcCapability tail:SmcCapList = SmcCapList;
dns_smc_address#9fd3 smc_addr:MsgAddressInt flags:(## 8) { flags <= 1 }
cap_list:flags . 0?SmcCapList = DNSRecord;
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
Proposal that will prevent the loss of user funds in case of erroneous sending
TON is a blockchain for massadoption, so we propose a number of guidelines and small changes in the address format,
so that even if the inexperienced user is inattentive and sends funds to the wrong place, the funds were not lost and bounced back to him in most cases.
This proposal describes changes that almost do not break backward compatibility. However, at the same time we can discuss other proposals, including more radical ones.
Examples of cases where a user can lose funds:
The user copied the address in the testnet service, but mistakenly interacts with it or sends coins to it from the mainnet wallet app.
Since there will be no such address in the mainnet, the wallet app will now set the non-bounceable mode and send coins that will remain at the destination address and will be lost
Let's imagine a smart contract for the sale of NFT (for example, belonging to some marketplace), after receiving Toncoins from the buyer, this contract sends NFT to the buyer and destroy itself, because its mission is completed.
However, the UI may not be updated immediately and another user may send Toncoins for purchase to this contract address. Since the contract will no longer exist, the wallet app will set non-bounceable mode and Toncoins will remain forever at the destination address and will be lost.
At the moment, most marketplaces bypass this by not destroying the sale smart contract.
The smart contract of the service (e.g. DEX) has not been deployed yet, but the user has already sent coins there, the wallet app will set non-bounceable mode and Toncoins will remain forever at the destination address and will be lost.
Suggested behaviour:
All TON apps and services must show addresses with a testnet flag set if they are on a testnet network.
All TON apps and services should reject addresses with a testnet flag set if they are on a mainnet network.
For example, mainnet wallets should not allow sending coins to a testnet address in any way.
User apps and services should only accept addresses in user-friendly format and not accept addresses in raw format.
All services must only display and accept urlsafe format, and not operate with non-urlsafe form.
All wallets should show non-bounceable addresses.
All other smart contracts should always show in bounceable form.
The creators of such smart contracts (for example, DEXes) must first deploy such smart contracts themselves in order for the bounceable form of the address to be applicable.
bounceable
flag from address representation should now be taken as "force-bounceable".When sending, wallets must accept this flag as follows:
if
true
- all messages to this address can ONLY be sent in bounceable mode, even if the destination contract has anuninitialized
state.if
false
- means that a non-bounceable message can be sent to the destination address.The wallet app checks the destination address - if it has an
uninitialized
state, then it sends a non-bounceable message, otherwise it sends a bounceable message.Since only wallets will use the non-bounceable form, it will also be possible to distinguish the wallet from the service smart contract using this flag.
Migration Plan
Since there are already many services and applications in the TON network, it makes sense to carry out the migration in stages:
All popular services must apply a testnet flag to the addresses on their testnet versions.
All popular wallets and services (such DEX'es or NFT marketplaces) must reject destination testnet addresses in mainnet.
All popular services must not display and accept "raw" address form and non-urlsafe form.
All popular wallets must show user's address in non-bounceable form.
This modifies only the leading and last characters of the address, while the body of the address remains the same.
However, changing the address may confuse some users, so advance warning and explanation in public channels is needed.
All popular exchanges and services must show deposit addresses in non-bounceable form.
All popular exchanges should not allow withdrawals to non-wallet addresses (to non-bounceable addresses).
After that all popular wallets must implement new
bounceable
flag algo.Suggested behaviour of TON DNS:
The DNS recode scheme assumed a
cap_is_wallet
flag (which allow to send non-bounceable messages).However, this flag was not widely used and applied in practice.
Based on the fact that DNS names are mainly used for user wallets and to a much lesser extent for service addresses, we propose to introduce the flag
cap_only_bounceable
which will mean that non-bounceable message should never be sent to this address.
DNS records of addresses of existing services can be updated, because this is in the interests of the services themselves.
Suggested behaviour of TON Connect
TON Connect methods (such as
sendTransaction
) must accept a domain or address in user-friendly form as the destination address, and not accept the raw form.A dapp that calls such a method either received this address from the user, or knows the type of smart contract (for example, it sends a transaction to the DEX smart contract, which means bounceable form).