To set up an account on the NEAR blockchain, it requires you to send some number of tokens to fund that account. For example, when using the NEAR Wallet to set up a new account, you have to fund it with 3N first. Why is this?
You can create a NEAR "implicit" account with 0 NEAR. Near implicit accounts are the same as in Ethereum or Bitcoin. You create the a keypair locally and the public key becomes your account id (a hex string, like in Ethereum or Bitcoin)
See here: https://nomicon.io/DataStructures/Account.html
and here: https://docs.near.org/docs/roles/integrator/implicit-accounts
You only need 3 NEAR if you want to create a "named" account, that is an account like alice.near that's way easier to use than implicit accounts like 641537c21dC82F97b7fC8AD778e99997beeE0d73
On NEAR, data usage is "funded" by holding a balance of tokens on the account which reserves the storage space. So, in order for the account to be created, it has to set aside some storage on the chain, which requires some amount of tokens to "pay" for those initial bytes of memory by sitting on the account.
This minimum balance depends on how much data the account uses and could start as low as < 1N for a basic account to ~40N for one with multifactor authentication and other bells and whistles added to it.
For more, see the docs at https://docs.near.org/docs/concepts/storage which describe the "state staking" approach used here.
Related
Given I want to let someone without a NEAR account call a specific function in a smart contract, and to do so I create a function access key for my own account with permissions limited to that specific contract and function.
Will I then risk anything else than the allowance (0.25N) granted to that function access key?
Is it a bad idea to even share that access key publicly, let's say if I want to include that access key in a link?
I could of course also create an implicit account and then a function access key from that, but is it really necessary from a security point of view?
What you're describing is the basis for what's known as a linkdrop. You can learn more about how those work here.
To answer your question, it depends on what that function call access key can do. If it can call a method withdraw that can withdraw $NEAR from your contract account with no limits, then it's probably not a good idea to share it publicly.
If you're confident that the key cannot be used in a malicious way to steal assets or do things that are unwanted, then there is no risk in sharing it publicly.
I would also stress that the 0.25 $NEAR allowance is NOT saying "this key can be used to withdraw up to 0.25 $NEAR on my account". That allowance is for transactions fees ONLY (Gas). 0.25 $NEAR equates to roughly 2.5 PetaGas (2500 TGas) which is a lot of computation power and can be used to call a method many times. What happens in that method, however, has nothing to do with the allowance.
You can spend 0.01 $NEAR worth of allowance (100 TGas) and call a method which withdraws 1000 $NEAR from the contract account. The allowance is ONLY for computation.
TLDR: it depends on what the key can do and allowance != net outbound NEAR from a contract account.
I uploaded and created a new smart contract. I sent 1000 units to this smart contract.
However when the contract is deployed the transferable is not equal to 1000.
And when I execute any function it also deducts the transferable.
Is there any way to prevent this. I want to deduct user token instead of the smart contract token. In Ethereum, the user token is deducted.
I want to deduct user token instead of the smart contract token. In Ethereum, the user token is deducted.
I think there is a misunderstanding here, you probably understood the deducted tokens as gas. But gas is deducted from the instantiating account (what you referred to as "user token"), same as in Ethereum.
The amount that is deducted from the contract here is state rent ‒ i.e. the contract has to regularly pay for the amount of state and code storage it uses. This is a concept which is currently used by the contracts pallet to reduce state bloat. I won't link to the documentation here though, since a new paradigm will be introduced soon, making it obsolete.
I learned that data storage on NEAR protocol requires to stake NEAR tokens. Is there a way to monitor the total amount of data stored on chain? Didn't find it on NEAR Explorer (or perhaps didn't look at the right place)
The increase/decrease in storage use automatically locks some of the tokens on the account. Explorer displays "STORAGE USED" on the account details page (example). mainnet is configured (see EXPERIMENTAL_protocol_config JSON RPC method for other config options) to have "storage_amount_per_byte": "100000000000000000000", which means that 100kb of data (smart contract code, smart contract state, account access keys, and profile data [liquid balance, locked balance, account id]) locks 1 NEAR on your account (so you just cannot transfer/spend those tokens unless you remove something from the storage).
I use scopes:
https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/userinfo.email
but result data of:
https://www.googleapis.com/oauth2/v1/userinfo
https://www.googleapis.com/oauth2/v3/tokeninfo
not contains info about exist two-factor auth on google account.
Can I get boolean or another value about it?
Sorry we don't expose If a user has 2 factor auth or not) through API. We have been thinking about this for a while.
We have been doing a lot of things to improve the security for all users (including the ones who have not enabled 2nd factor). This is based on the risk signals and we ask for second factor if the user has a phone # on their account even without a user enabling "strict" 2nd factor. This allows us to protect all users. The difference being in one case 2nd factor is required in all sign-in vs required when we think there is risk.
The problem is that if we do expose whether a user has enabled strict 2nd factor, a lot of 3rd parties will "force" users to become a "strict" 2 factor users without understanding what that means. So for now we don't have a timeline.
I am currently in the process of planning & developing an integrated application using Stripe in addition to some other technologies (a combination of backbone & laravel). As a result I am using Stripejs in combination with the PHP stripe library.
I use stripejs to send Stripe their account info (for savings accounts I send country, routing and account numbers via stripes js lib, I then save off the created token in the response to the backend). I am attempting to transfer money to various recipients following charging accounts (so I have money in my stripe account) but I am a bit confused over exactly what approach to take.
My main questions are as follows.
If I am positive of the identities of the individual’s using the application, is verification required (5 – 10 people max will be using)?
If it is required what is the best approach to verifying the user using the current technique I am using (create a token, save off on the backend)?
From my experience with Stripe, you don't need to 'verify identities' each time you use a token, so long as a customer has been set up for recurring use. So as long as your application is properly secured so that only the 5-10 people can use it, and can only process payments for their own accounts, you are good to go. In other words, you obviously want to do your own user verification to make sure only valid people can use the application, but you don't need to do it as far as Stripe is concerned.
That said, if you are in essence transferring money between people, you might want to go the extra distance and make sure that the user has the correct card number or bank account number each time. In which case I would use something like:
Get user data using tokens stored in DB.
$cu = Stripe_Customer::retrieve("cus_4pn93XXXXXXXXXXX");
$card = $cu->cards->retrieve("card_14g7ZU4rLTyXXXXXXXXXXX");
If Stripe's returned data matches user-submitted data, you know you have the correct user. In particular, if the last 4 digits of the card and the expiry date match the last 4 returned by Stripe and the Stripe returned expiry date, you can be reasonably sure (albeit not certain) that the person actually possesses the card in question.