neo-project / proposals Goto Github PK

I believe NEP-7 (Triggers on NeoContract) can be fully replaced by a new token standard that allows recipient verification.
This standard would require users to validate receiving funds, if they require that. This is useful and necessary for many real-world situations, for compliance reasons. It could even make things a lot safer in blockchain world, by avoiding tokens to be burned when sent to wrong addresses (see neo-project/neo#195).
This standard would require a user to explicitly set receiving flag to true (and proving its ownership of the empty account), before receiving assets. So, by default, it will be impossible to burn tokens sending them to random accounts because no one will even own them (we can leave a special one for burning, like 00000....0000 which reduces total supply).
Some nice options could also exist, for example: receiveOnce (once received, lock mechanism goes to false again); allowAirdrops (this would allow receiving tokens marked as airdrop flag), etc.

I believe VerificationR won't be necessary anymore for Neo 3.0, and this token NEP-7 does a better job. I haven't thought yet about ApplicationR, any ideas?

There is no process for status of NEPs, there is already the case of NEPs that where accepted without any general agreement or acceptance from the broader community like NEP-7. There is need to formalize the process of how status are changed in NEPs.

When consulting NEP-1 (https://github.com/neo-project/proposals/blob/master/nep-1.mediawiki) there is just a generic description without an actual specification of what acceptance of community means, there is need to be a voting process and a balanced selection of voting participants.

Hi, Can we have one KYC for all neo ico's? It can be linked to existing neo wallet. I dont wont my passports to be sent each and every ico on neo.

I believe the NEP-11 standard could use some clarification when it comes to the properties method.

The official standard (here: https://github.com/neo-project/proposals/blob/master/nep-11.mediawiki) states that for the properties method:

Returns a serialized NVM object containing the properties for the given NFT. The NVM object must conform to the "NEO NFT Metadata JSON Schema"

It also shows a signature like this

{
  "name": "properties",
  "safe": true,
  "parameters": [
    {
      "name": "tokenId",
      "type": "ByteString"
    }
  ],
  "returntype": "Map"
}

So this is the first issue, it's inconsistent, in one case it says a serialized NVM object, in the other it says a Map.

Also, I think for ease of use by wallets and dapps, one way to make it easier would be to allow the properties method to return a serialized json object, as it is way easier to deal with that, than to deal with a map / nvm objects directly (to avoid having to convert all base64 etc). A serialized json object also technically conforms to the standard since it is technically an NVM object, that also conforms with the json standard.

Thoughts?

Hereby, I can not find any wallet and smart tool for asset allocation.
Please help me a 3rd generation crytocurrency ..

Code

using Neo.SmartContract.Framework;
using Neo.SmartContract.Framework.Services.Neo;
using Neo.SmartContract.Framework.Services.System;
using System;
using System.Numerics;

namespace ICO_Template
{
    public class ICO_Template : FunctionCode
    {
        public static Object Main(string operation, params object[] args)
        {
            if (Runtime.Trigger == TriggerType.Verification)
            {
                return Withdrawal(operation.AsByteArray());
            }
            else if (Runtime.Trigger == TriggerType.Application)
            {
                if (operation == "MintTokens") return MintTokens();
                if (operation == "TotalSupply") return TotalSupply();
                if (operation == "Name") return Name();
                if (operation == "Symbol") return Symbol();
                if (operation == "Transfer")
                {
                    if (args.Length != 3) return false;
                    byte[] from = (byte[])args[0];
                    byte[] to = (byte[])args[1];
                    BigInteger value = (BigInteger)args[2];
                    return Transfer(from, to, value);
                }
                if (operation == "BalanceOf")
                {
                    if (args.Length != 1) return 0;
                    byte[] address = (byte[])args[0];
                    return BalanceOf(address);
                }
                if (operation == "Decimals") return Decimals();
                if (operation == "Deploy") return Deploy();
                if (operation == "Refund") return Refund();
            }
            return false;
        }
        // initialization parameters, only once
        // 初始化参数
        public static bool Deploy()
        {
            byte[] owner = new byte[] { 2, 133, 234, 182, 95, 74, 1, 38, 228, 184, 91, 78, 93, 139, 126, 48, 58, 255, 126, 251, 54, 13, 89, 95, 46, 49, 137, 187, 144, 72, 122, 213, 170 };
            BigInteger pre_ico_cap = 30000000;
            uint decimals_rate = 100000000;
            byte[] total_supply = Storage.Get(Storage.CurrentContext, "totalSupply");
            if (total_supply.Length != 0)
            {
                return false;
            }
            Storage.Put(Storage.CurrentContext, owner, IntToBytes(pre_ico_cap * decimals_rate));
            Storage.Put(Storage.CurrentContext, "totalSupply", IntToBytes(pre_ico_cap * decimals_rate));
            return true;
        }
        // The function MintTokens is only usable by the chosen wallet
        // contract to mint a number of tokens proportional to the
        // amount of neo sent to the wallet contract. The function
        // can only be called during the tokenswap period
        // 将众筹的neo转化为等价的prx tokens
        public static bool MintTokens()
        {
            byte[] neo_asset_id = new byte[] { 197, 111, 51, 252, 110, 207, 205, 12, 34, 92, 74, 179, 86, 254, 229, 147, 144, 175, 133, 96, 190, 14, 147, 15, 174, 190, 116, 166, 218, 255, 124, 155 };
            Transaction trans = (Transaction)ExecutionEngine.ScriptContainer;
            TransactionInput trans_input = trans.GetInputs()[0];
            byte[] prev_hash = trans_input.PrevHash;
            Transaction prev_trans = Blockchain.GetTransaction(prev_hash);
            TransactionOutput prev_trans_output = prev_trans.GetOutputs()[trans_input.PrevIndex];
            // check whether asset is neo
            // 检查资产是否为neo
            if (prev_trans_output.AssetId != neo_asset_id)
            {
                return false;
            }
            byte[] sender = prev_trans_output.ScriptHash;
            TransactionOutput[] trans_outputs = trans.GetOutputs();
            byte[] receiver = ExecutionEngine.ExecutingScriptHash;
            long value = 0;
            // get the total amount of Neo
            // 获取转入智能合约地址的Neo总量
            foreach (TransactionOutput trans_output in trans_outputs)
            {
                if (trans_output.ScriptHash == receiver)
                {
                    value += trans_output.Value;

                }
            }
            // the current exchange rate between ico tokens and neo during the token swap period
            // 获取众筹期间ico token和neo间的转化率
            uint swap_rate = CurrentSwapRate();
            // crowdfunding failure
            // 众筹失败
            if (swap_rate == 0)
            {
                byte[] refund = Storage.Get(Storage.CurrentContext, "refund");
                byte[] sender_value = IntToBytes(value);
                byte[] new_refund = refund.Concat(sender.Concat(IntToBytes(sender_value.Length).Concat(sender_value)));
                Storage.Put(Storage.CurrentContext, "refund", new_refund);
                return false;
            }
            // crowdfunding success
            // 众筹成功
            long token = value * swap_rate;
            BigInteger total_token = BytesToInt(Storage.Get(Storage.CurrentContext, sender));
            Storage.Put(Storage.CurrentContext, sender, IntToBytes(token + total_token));
            byte[] totalSupply = Storage.Get(Storage.CurrentContext, "totalSupply");
            Storage.Put(Storage.CurrentContext, "totalSupply", IntToBytes(token + BytesToInt(totalSupply)));
            return true;
        }
        // The function Withdrawal is only usable when contract owner want
        // to transfer neo from contract
        // 从智能合约提取neo币时，验证是否是智能合约所有者
        public static bool Withdrawal(byte[] signature)
        {

            byte[] owner = Storage.Get(Storage.CurrentContext, "owner");
            return VerifySignature(owner, signature);
        }
        // list of crowdfunding failure
        // 众筹失败列表
        public static byte[] Refund()
        {
            return Storage.Get(Storage.CurrentContext, "refund");
        }
        // get the total token supply
        // 获取已发行token总量
        public static BigInteger TotalSupply()
        {
            byte[] totalSupply = Storage.Get(Storage.CurrentContext, "totalSupply");
            return BytesToInt(totalSupply);
        }
        // get the name of token
        // 获取token的名称
        public static string Name()
        {
            return "ICO";
        }
        // get the symbol of token, symbol used to represent a unit of token
        // 获取token的单位
        public static string Symbol()
        {
            return "ICO";
        }
        // function that is always called when someone wants to transfer tokens.
        // 流转token调用
        public static bool Transfer(byte[] from, byte[] to, BigInteger value)
        {
            if (!Runtime.CheckWitness(from)) return false;
            if (value < 0) return false;
            byte[] from_value = Storage.Get(Storage.CurrentContext, from);
            byte[] to_value = Storage.Get(Storage.CurrentContext, to);
            BigInteger n_from_value = BytesToInt(from_value) - value;
            if (n_from_value < 0) return false;
            BigInteger n_to_value = BytesToInt(to_value) + value;
            Storage.Put(Storage.CurrentContext, from, IntToBytes(n_from_value));
            Storage.Put(Storage.CurrentContext, to, IntToBytes(n_to_value));
            Transferred(from, to, value);
            return true;
        }
        // triggered when tokens are transferred
        // 事件机制，可通知客户端执行情况
        private static void Transferred(byte[] from, byte[] to, BigInteger value)
        {
            Runtime.Notify("Transferred", from, to, value);
        }
        // get the account balance of another account with address
        // 根据地址获取token的余额
        public static BigInteger BalanceOf(byte[] address)
        {

            byte[] balance = Storage.Get(Storage.CurrentContext, address);
            return BytesToInt(balance);
        }
        // get decimals of token
        // 获取token精度
        public static BigInteger Decimals()
        {
            return 8;
        }

        // The function CurrentSwapRate() returns the current exchange rate
        // between ico tokens and neo during the token swap period
        private static uint CurrentSwapRate()
        {
            BigInteger ico_start_time = 1502726400;
            BigInteger ico_end_time = 1506258000;
            uint exchange_rate = 1000;
            BigInteger total_amount = 1000000000;
            uint decimals_rate = 100000000;
            uint rate = decimals_rate * exchange_rate;
            byte[] total_supply = Storage.Get(Storage.CurrentContext, "totalSupply");
            if (BytesToInt(total_supply) > total_amount)
            {
                return 0;
            }
            uint height = Blockchain.GetHeight();
            uint now = Blockchain.GetHeader(height).Timestamp;
            int time = (int)now - (int)ico_start_time;
            if (time < 0)
            {
                return 0;
            }
            else if (time <= 86400)
            {
                return rate * 130 / 100;
            }
            else if (time <= 259200)
            {
                return rate * 120 / 100;
            }
            else if (time <= 604800)
            {
                return rate * 110 / 100;
            }
            else if (time <= 1209600)
            {
                return rate;
            }
            else
            {
                return 0;
            }

        }
        private static BigInteger BytesToInt(byte[] array)
        {
            var buffer = new BigInteger(array);
            return buffer;
        }

        private static byte[] IntToBytes(BigInteger value)
        {
            byte[] buffer = value.ToByteArray();
            return buffer;
        }
    }
}

Notes

Methods used by the client with public function, the other with private function

Hi, everyone.

@lerider commented about his idea to design a donation address, which would be able to send GAS but do not send Neo assets (claim would be a source of tokens for the charity and is, consequently, needed. Thus, send NEO to itself should be allowed).

The first idea (@igormcoelho) was to design something like this:

// NEP Charity Donations - Remote GAS Claim
using Neo.SmartContract.Framework;
using Neo.SmartContract.Framework.Services.Neo;
using Neo.SmartContract.Framework.Services.System;
using System;

namespace Neo.SmartContract
{
    public class NepCharityDonation : Framework.SmartContract
    {
        private static readonly byte[] Owner = "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y".ToScriptHash();
        private static readonly byte[] Charity = "APLJBPhtRg2XLhtpxEHd6aRNL7YSLGH2ZL".ToScriptHash();
        private static readonly byte[] NeoAssetId = { 155, 124, 255, 218, 166, 116, 190, 174, 15, 147, 14, 190, 96, 133, 175, 144, 147, 229, 254, 86, 179, 74, 92, 34, 12, 205, 207, 110, 252, 51, 111, 197 };
        private static readonly byte[] GasAssetId = { 231, 45, 40, 105, 121, 238, 108, 177, 183, 230, 93, 253, 223, 178, 227, 132, 16, 11, 141, 20, 142, 119, 88, 222, 66, 228, 22, 139, 113, 121, 44, 96 };

        // Verification Contract (no need for deploy)
        public static bool Main()
        {
            // Owner can manage all funds
            if(Runtime.CheckWitness(Owner))
               return true;
            // Verify if it's the Charity address   
            if(Runtime.CheckWitness(Charity))
            {
                // Get outputs
                Transaction tx = (Transaction)ExecutionEngine.ScriptContainer;
                TransactionOutput[] outputs = tx.GetOutputs();
                // Verify if this is a self transfer of NEO
                if((outputs.Length == 1) && (outputs[0].AssetId == NeoAssetId) && (outputs[0].ScriptHash == ExecutionEngine.ExecutingScriptHash))
                    return true;
                // Verifing if all outputs are GAS type
                foreach (TransactionOutput output in outputs)
                    if (output.AssetId != GasAssetId)
                        return false;
                return true;
            }
            
            return false;
        }
    }
}

However, we realized that we should use VerifySignature instead of Runtime.CheckWitness, which requires us to send signature as a parameter, right?

What do you recommend, @erikzhang ?

A1) VerifySignature would imply in an adjustment on the wallet for sending from this type of address.
A2) We could design other type of contract that blocks sending to other addresses.
But, perhaps, a password should be used for avoiding malicious transfer back to the OWNER (which would bother the charity address).

using Neo.SmartContract.Framework;
using Neo.SmartContract.Framework.Services.Neo;
using Neo.SmartContract.Framework.Services.System;
using System;
using System.ComponentModel;
using System.Numerics;

namespace NeoContract1
{
    public class CharitySimpleExample : SmartContract
    {

        private static readonly byte[] neo_asset_id = { 155, 124, 255, 218, 166, 116, 190, 174, 15, 147, 14, 190, 96, 133, 175, 144, 147, 229, 254, 86, 179, 74, 92, 34, 12, 205, 207, 110, 252, 51, 111, 197 };
	private static readonly byte[] gas_asset_id = { 231, 45, 40, 105, 121, 238, 108, 177, 183, 230, 93, 253, 223, 178, 227, 132, 16, 11, 141, 20, 142, 119, 88, 222, 66, 228, 22, 139, 113, 121, 44, 96 };

	//The guy who donate the NEO for charity and can without anytime
	public static readonly byte[] Owner = "ATrzHaicmhRj15C3Vv6e6gLfLqhSD2PtTr".ToScriptHash();

      
	//This is the unic addres able to transfer the GAS
	public static readonly byte[] RegisteredClaimAddres = "ATrzHaicmhRj15C3Vv6e6gLfLqhSD2PtTr".ToScriptHash();

        public static object Main(string operation, params object[] args)
        {
            if (Runtime.Trigger == TriggerType.Verification)
            {

                if (operation == "ownerWithdrawn")
                {
                    // if param Owner is script hash
                    return Runtime.CheckWitness(Owner);
                }

               
               Transaction tx = (Transaction)ExecutionEngine.ScriptContainer;
               TransactionOutput[] outputs = tx.GetOutputs();
               TransactionInput[] inputs = tx.GetInputs();
               
               bool canWithdraw = true;
               foreach (TransactionOutput output in outputs)
               {
                	if (output.AssetId == gas_asset_id && output.ScriptHash != RegisteredClaimAddres)
                	{
			    canWithdraw = false;
			}

                	if (output.AssetId == neo_asset_id && output.ScriptHash != Owner)
                	{
			    canWithdraw = false;
			}
               } 
               
               return canWithdraw;
            }//finish trigger verification, the only one able to withdraw

	        return false;         
        }

    }
}

This is a generalization of NEP #97, that can completely replace it, in a more efficient and well designed format.

The idea is similar to #97, this will ensure, from client side, that some data existed before some operation happened. The original one was only focused on assets, but with the effect that, if the chain behavior was changed and affected transfer, all future transfers would also fail (leading to an intended catastrophic event, that would prevent breaking changes on this perspective).

This proposal is broader, thanks to the observation by @joeqian10 (please correct me if I marked the correct handle here), that we need something that ensures correctness on every storage type. Thanks to that quick discussion, here follows the proposal.

The idea is to use a witness for every intended storage verification, with two big advantages:

1. although this occupies space on transaction, witnesses are likely to vanish if necessary
2. witnesses can allow for maleable behavior on InvocationScript

What we need on consensus side is:

1. computed state trie hash (distributed via p2p on next block proposal round, although not strictly necessary here)
2. a new operation, to check state hash proof.

For (2) I strongly defend that we have this operation on VM, as an Extension, rather than a Neo interop. The reasons are:

1. all Neo ecosystem blockchains (that run NeoVM) will require this feature too, so interop is limiting in this behavior
2. this will enforce even more the natural ability of NeoVM to handle complex cryptographic operations, something that doesn't exist somewhere else

Now, the general workflow is:

1. user claims the usage of this NEP, since it will require some crosschain or any other safe operation. It will pay more network fee, to acomplish this, including more witnesses than originally necessary, but with the benefits of guaranteeing storage correctness, even in the face of protocol changes/bugfixes. User attaches this proof on InvocationScript, and VerificationScript will just check that hash proof matches (using new operation)
2. naturally, this tx will pass, as witness will be valid for all nodes that have same storage state for that proof.
3. tx will enter block and be executed.
4. this should be very rare, but some bugfix may happen, affecting some past storage state
5. this will eventually change global hash for that past transaction...
6. user (or consensus node), may re-calculate the proof (that's why this NEP is required, to establish a standard on that), thus changing the InvocationScript, but preserving VerificationScript. This new InvocationScript should be valid, and re-distributed via regular means.
7. failure to re-calculate the proof will indicate that this is a breaking change, thus violating Neo Protocol regarding this change (that cannot be undone).

positive aspects: this allows bugfixes, verifiable storages and cross-chain, at the same time, which is quite unique and amazing.

negative aspects: this is complex (but not tooooo complex), and after is done, users will love to keep their one-block finality together with safe states and bugfixing.

Proposal

Name: NEP-51
Title: Token Standard Requiring Optional Methods
Author: [email protected]
Status: Draft
Created: 21 July 2018
Resolution: #58

Abstract

In the absence of NEP-5 reversion to Final state going through (issue #57), I propose NEP-51 (5.1), which requires the optional methods recently removed from the NEP-5 standard.

See: #58 for a draft of NEP-51, which is just the original NEP-5 with optional methods made required.

NEF is Neo executable format, I think we should make it a NEP standard.

namespace Neo.SmartContract
{
    /// <summary>
    /// +------------+-----------+------------------------------------------------------------+
    /// |   Field    |  Length   |                          Comment                           |
    /// +------------+-----------+------------------------------------------------------------+
    /// | Magic      | 4 bytes   | Magic header                                               |
    /// | Compiler   | 32 bytes  | Compiler used                                              |
    /// | Version    | 16 bytes  | Compiler version (Mayor, Minor, Build, Version)            |
    /// | ScriptHash | 20 bytes  | ScriptHash for the script                                  |
    /// +------------+-----------+------------------------------------------------------------+
    /// | Checksum   | 4 bytes   | Sha256 of the header (CRC)                                 |
    /// +------------+-----------+------------------------------------------------------------+
    /// | Script     | Var bytes | Var bytes for the payload                                  |
    /// +------------+-----------+------------------------------------------------------------+
    /// </summary>
    public class NefFile : ISerializable

original posted at neo-project/neo#889 neo-project/neo#903

The NEP5 spec (https://github.com/neo-project/proposals/blob/master/nep-5.mediawiki) states that there are to be a Required method and a Required event both called transfer. This isn't allowed in C#.NEO.

The specification needs to be corrected/updated. It's not strong enough to be implemented reliably on the NEO platform as it is written.

There were changes directly on the NEP-3. This brings a lot of confusion to the community, IMHO.
If NEP-3 (or NEO-6) is modified in some fundamental way, then, let's do another NEP standard as any other blockchain project. In the example from above, removing an entrypoint is a fundamental change. For sure, no doubts.

If only pieces of text and no functionality is modified, then, it's fine, it's just an amendment and the NEP number should remain untouched.

original posted by @gsmachado

What do you think? @neo-project/core

I believe NeoContract ABI (https://github.com/neo-project/proposals/blob/master/nep-3.mediawiki) may have useful ammendments:

1. Officially support "Map" types, as proposed by Ricardo some time ago
2. Support "Any" type for return and parameters. This was unofficially supported on C# compiler, and further changed to ByteArray, but it would be really better to allow returning and receiving any type of stack item (BigInteger, ByteArray, Map, etc) officially in some dapp functions
3. Few wording changes, such as explaining Signature format as a 64-byte signature regarding Neo supported ECDSA standard (secp256r1), or even keeping this open to future possibilities on signature formats (with even different sizes if needed to)

Since NEP-10 was marked obsolete once the SupportedStandards was moved to the manifest, there is no current NEP I can find that specifies how the name and number of the NEP should be formatted.

NEP-10 was specific in saying The return values {"nep-5"}, {"NEP5"}, and {"nep5"} will generally be considered invalid responses unless "nep5", for example, is a valid code for a specification in a non-NEP specification system.

NEP-15 does say The supportedstandards field describes the NEP-10 values. but now that NEP-10 is obsolete, maybe the formatting guidelines should be moved into NEP-15.

8c6b427#diff-e5a1452ea0de8fa24b9c328151e94aff

Projects deployed on mainnet have implemented these optional methods. I don't agree that they should have been removed from a proposal that had been marked as final and I put forward that they should be restored.

If a new token standard is to be defined without the optional methods then a completely new proposal should be submitted for discussion.

A C# SC implementation that is compliant with NEP-5 does not need nor is it required to implement any of the methods as described in the current (updated) version of the NEP-5 specification.

The updated NEP-5 specification is misleading.

Reference: #44 (comment)

Joe and I are looking for feedback and will post this draft shortly to #dev-general.

https://github.com/mwherman2000/proposals/blob/master/NEP-8.mediawiki [updated]

[It was short - 1 operation/method - so it was easy to write it up to get actual feedback.]

This NEP is very timely and relevant. Looking forward to everyone's feedback.

This based on the work Joe Stewart has done with Non-Fungbile Token extensions to NEP-5 and the work I've done to support NEP-5 extensions for Requisitions.

How to signMessage,


It's so difference!

For exemple:
salt = 058b9e03e7154e4db1e489c99256b7fa;
message = Hello World!
The first:
messageHex = 01000f0 + salt.length + message.toHex + salt + message + 0000
The second:
messageHex = 01000f0 + (salt+message.toHex).length/2 + salt + message.toHex + 0000

Which kind of signature is right ？
And The source code of verifyMessage

I tried the exemple


the result is false

My suggestion is that the diffusion protocol changes to a more randomized one in order to make it less predictable.

Credit where it is due, here is a very good explanation applied on bitcoin:
http://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/dandelion/

This project seems really interesting but straightforward and would be a very good implementation to protect the average user.

It is also very easy to see that it's wrote about bitcoin but it can be applied for any blockchain

Do we have transferFrom method on NEP-5?
Because it's not on spec (yet). Question is: if we have it, we should update spec asap.
If we want it, but not on NEP-5, will we create another spec for it?

Issue:
Url outdated

At:
https://github.com/neo-project/proposals/blob/master/nep-2.mediawiki#implementation

From
CityOfZion/neon-js: https://github.com/CityOfZion/neon-js/blob/master/src/nep2.js

To
CityOfZion/neon-js: https://github.com/CityOfZion/neon-js/blob/master/src/wallet/nep2.js

For example, NEX has some extensions to NEP-5 that they want to call NEP-5.1.
@saltyskip has some NFT extensions that I think he wants to call NEP-5.1.
@mwherman2000 (moi) has some NEP-5 extensions for processing remittances ...maybe I want to be the ".1" in NEP-5.1?

I don't think it makes sense to have decimal parts in NEP numbers.

Who has the right to be ".1", who is ".2"? If you're the ".1", do you also have first rights to become ".2" or ".3"? If you're the ".1" and my spec is the ".2" and some other unrelated spec is ".3", will that make sense to anyone 1, 5, 10 years from now?

The whole situation is avoidable if we stick to whole numbers (i.e. positive integers) e.g. NEP-1234

Do you agree?

p.s. Decimal NEP numbers sort of sound like versioning which is also not a good idea and goes against the spirit of NEP-10. If you want a new or different interface, create a new NEP (or NCP).

Hello,

Could you guys create the NEO 3.0 milestone in this repository?
I was reading NEO 3.0 issues and noticed that there are a few links to this repository but there is no milestone. Maybe this can help to choose what NEPs are going to be implemented in version 3.0?

Thanks

Currently, Neo don't have a unified style for upgrade method writing in SC so that neo-cli or neo-gui can't implement a command or a button for upgrade intergration. However, upgrade is very important for Dapp devlopment.
@erikzhang

Summary: this NEP called Transfer to Transaction tries to provide a practical manner to redistribute assets during Verification time on transaction, thus allowing implementation of practical mechanisms for "free transactions".

[EDIT 1] - This doesn't affect NEP-17 in any case. At the time of writing, this is mainly intended for adoption only on GAS contract, as NEP-17 and NEP-TTT.
[EDIT 2] - Two methods are proposed in this NEP: scheduleTransfer and finalizeTransfer.

[ORIGINAL PART]

=====

Transfer to Transaction

This NEP considers a transaction as a valid (and temporary) token holder (as HASH256 identifier, not usual HASH160).
It can be done with operation "contract.scheduleTransfer(from, target_tx, value)" that launches a "promiseNotification" (consumed before actual contract invocation).
Contracts can easily extract funds from transaction, for example, in a mint operation. Neo system can also consume funds from Transaction, for example, GAS funds to cover fee for operations. User can also specify a "contract scope" or "group scope" as the temporary holder (instead of global "transaction scope") and funds are consumed according to the scope.

Example 1 (usual operation):

• User transfers its own 0.5 GAS to TxA (on tx header) - Note that this works as a fee field on transaction and script runs directly from Witness
• User calls transfer operation for ContractY NEP17 (on tx invocation) and uses GAS stored on tx for operations

Example 2:

• User "requests" 0.5 GAS from ContractY to TxA (on tx header)
• User calls transfer operation for ContractY NEP17 (on tx invocation) and uses GAS stored on tx for operations

This "request" operation at ContractY can do some interesting thing such "redistributing" GAS for user operation, in that specific scope, with some simple rule as:

• gas_request < User_NEP17_Balance_at_ContractY / NEP17_Total_Supply * GAS_Balance_at_ContractY * (1 - RELATIVE_HOLD_TIME)
• gas_request < max_gas_request => (some contract-specific constant tighter than the constraint above)
• RELATIVE_HOLD_TIME = last_balance_change / contract_specific_hold_constant (blocks)
• last_balance_change > XYZ (blocks)

This means that giveaway operation only works after few blocks, and with limited gas supply (limited per block hold time and user shares on that contract).

We are proudly to propose a first draft on how Merkle State Proofs could be easily used to validate storage and voting information, also to provide a simple transition to a Neo blockchain without UTXO model.
We would be happy to have more names in this NEP, so if you want to contribute, please join us :)

#74

{"NEP-5", "NEP-8", "NEP-1234"}
should be changed to
{"NEP-5", "NEP-10", "NEP-1234"}

If add, which do you prefer?

Option1: extend NEP3
Option2: create a new NEP14

This is a polemic proposal, but that is why we are here.
First of all, there is a strict line between censorship resistance and transparency.

Motivation

• Currently, blocked account are hardcoded as a configuration of the node clients: https://github.com/neo-project/neo-plugins/blob/db04e756a64c149e86d117fe89879c72f319c7df/SimplePolicy/SimplePolicy/config.json#L7-L10;
• While we do not have any blocked accounts, we can imagine several specific scenarios in the future where an account should be blocked;
• Nowadays, validators are the only ones really able to filter transactions (it will be kept like that in the proposal).

Solution

• Every voting rule is subjected to a bias, that is why this proposal does not change the way a transaction is filtered compared to the current state;

• In order to achieve better transparency in such aforementioned cases, the idea is to deploy a smart contract with some basic voting functions:

  • Every address can vote for blocking an account, however, only validators votes will still be really counted. This is done for promoting the possibility of public expressed opinions;
  • Receive a signed message with the blocked account;
  • If, at least, M validators decide to block an account it will enter in the list. Votes can be reverted at any time;
  • A function for a blocked account to present its public reply.

Solution positives aspects

• This will not change the current flow, however, promotes transparency;
• Neo Ecosystem will be prepared to face such situations in a decentralized and transparent fashion;
• Kleros platform sounds like an interesting case of study for this kind of proposals.

Expected deadline for implementation

This proposal does not need to be implemented in the next coming months/years, even in Neo 3.0.
Maybe this is a proposal for something in the future, such as Neo 4.0.

The NEP5 spec (https://github.com/neo-project/proposals/blob/master/nep-5.mediawiki) is unclear in its description of the intended NEP5 smart contract interfaces.

For example, it states that there is a Required and Optional set of methods that need to be implemented and that they need to be declared public. In addition, it doesn't mention any requirement for a Main method and it's parameters.

For example, the referenced example https://github.com/lllwvlvwlll/Woolong/blob/master/Woolong/Woolong.cs, declares these methods as private.

The specification needs to be corrected/updated. It's not strong enough to be implemented reliably on the NEO platform as it is written.

This is a follow-on to the acceptance of NEP-10 -- prompted by the following question in #dev-general:

Kev - Today at 8:00 AM
I see , thanks hal
@Michael Herman (Toronto) For NEP-10, if a user wanted to add a new set of methods to their token,
they would have to wait for it to be approved in the NEP standards? And if it does not get approved?
And If they only wanted or needed some of the required methods of a NEP, they would have to 
implement all of them due to stating that they support NEP-X
What about adding a method that returns an ABI for exposed methods?

Here's my reply suggesting we need something like NEO Community Proposals (NCPs)...

Michael Herman (Toronto) - Today at 9:25 AM
@Kev Hi... I was actually looking forward to someone asking this category of questions.  
Let me answer them in order.
1. RE: New methods/new NEP/needing to wait for approval/not being approved, etc.  This is the
most interesting question. I think we need a lightweight way for people to quickly submit "NEO
Community Proposals" (or something like that) and quickly receive a "number" ...e.g. ("NCP-1234")
...that they can use with NEP-10.  I see NCPs as potentially being an "on-ramp" to something
becoming an NEP.
2. RE: Needing to implement all of the required methods.  Yes this is a requirement.  The ABI
suggestion doesn't work because it would also need to work for SCs querying and calling other SCs.
ABIs (and JSON) are too complex to be processed internally by a SC 
(discussion: https://github.com/neo-project/proposals/issues/40#issuecomment-384995270).  
If an SC declares it supports "NEP-1234", then it is committing that it supports all of the 
operations/methods in NEP-1234.
Lastly, I want to see the NCP discussion become more formal/tracked.  I've opened this issue to
more formally track this idea: https://github.com/neo-project/proposals/issues/47
CC: @erik @tyler @Hal0x2328

Should we remove the from argument from NEP5 and use the Sender of the transaction in order to avoid user mistakes?

https://github.com/neo-project/proposals/blob/master/nep-5.mediawiki#transfer

Where:
https://github.com/neo-project/proposals/blob/master/nep-6.mediawiki#implementation

From
https://github.com/CityOfZion/neon-js/blob/feature/nep-wallet/src/wallet/Wallet.js

To
https://github.com/CityOfZion/neon-js/blob/master/src/wallet/Wallet.js

With the looming climate change emergency I have mixed feelings about Bitcoin.

Sure, it's a revolutionary system that challenges the very core of the financial/political status quo.

But I baulk at its environmental impact. What's the point in overcoming inequality if we destroy our very existence in the process?

I recently started to look into NEO's energy footprint. On the face of it the situation is much improved.

A consensus node only requires the hardware of a pretty average laptop (say 100W).

Therefore a single standard on-shore wind turbine (~2.5MW) could power 25,000 consensus nodes.

The largest off-shore wind turbines (~12MW) could power over 100,000 nodes.

So, at first glance, it seems there's no comparison between Bitcoin (consuming the energy requirements of a small country) vs NEO (a couple of wind turbines).

However, I don't yet fully understand the implications of the voting mechanism for NEO.

As the consensus is decided by having more nodes agree than don't agree, my fear is that a type of 'arms race' could be triggered due to competing NEO superpowers attempting to control the network.

This would result in each side attempting to gain more and more consensus nodes. The end result would be similar to the struggle for power by the Bitcoin mining community but with each side adding more and more nodes and could result in a vast increase in needless power consumption.

Would be interested to understand what NEO has in place to prevent such an 'arms race' from developing.

I gather there is no upper limit to the number of nodes that can be added to the network?

The NEP-5 token standard does not mandate a storage key format or expose a mandatory method to get the prefix or or format of storage keys for the contract. We need this in the token standard in order to be able to use Patricia Tree in Neo 3.0 to validate balances. Also we need it to track token balance changes more efficiently.

We intend to propose in the next weeks/months a draft of Quantum Security operations that could possibily become the NeoQS (mentioned in white paper).

NeoQS envisioned a cryptographic system based on Lattice problems. In particular, in the White Paper, a mechanism based on Shortest Vector Problem (SVP) and Closest Vector Problem (CVP) were considered.

State-of-the-art studies and reports points out that this family of problems can really generate Hard problems in worst case situation, even for average instances. On the other hand, slightly different mechanisms are being proposed, such as Learning with Errors (LWE) and its variant of Ring Learning with Errors (R-LWE).

These problems depend on the assumption of these NP-Hard problems keep hard, which is highly believed on the assumption that P != NP. Anyway, new cryptographic schemes may always be considered with care, as they can include other issues, so we will continue following the analysis of recent NIST reports, and propose a solution that could use hybrid cryptography (ECDSA + Quantum), which is safer for a transition involving classic and quantum computers.

Transaction price can be an issue, since signatures tend to be much bigger, but this is an issue that we can discuss in more details with the community for the future.

I would love that smart contracts could react to asset transfers, I'm not talking about the Mint function, but rather that a smart contract can react, execute, upon receiving NEO or any asset.
(remember our old friend AplicationR from NEP7?)

After studying several options we found that the solution is right in front of us.
In Native Contracts (NEO/GAS) we can add a call to the address in if the destination is a contract.

In the Transfer method of the native contracts we can include a check of whether the destination account is a contract address, check if it has the payable flag and if so, invoke a specific method of the contract, for example bool Payable()

Payable method can be included in the NEP5 standard and must return True if everything is correct or throw an exception otherwise.

In this way smart contracts can react to payments without users having to build a special transaction, invoke Mint or whatever.
Therefore, Mint invocations won't need a second APPCALL, saving network and blockchain resources.

It also gives to the contract full management of received payments such as denying money receipts, issuing refunds, etc ...

I propose we start discussions on security token standards for different jurisdictions to provide basic supports for the issuance and governance of securities on NEO. These standards should be embedded with regulations and take life cycle management of security into consideration.

I propose a NEP that will help us give much more control over token operations, specially on Neo 3 (although already applicable for Neo2, even existing NEP-5 tokens could do that without changing contracts). This proposal is simple: allow better balance tracing over storage-based assets, like NEP-5.
On UTXO, it's all connected, the past transactions, past balances, and current balance, giving great auditability capabilities.
On storage-based assets, such as NEP-5, we only execute some transfer operation on the chain, and our balance is automatically updated, but no record is kept for how much existed before (and after).

This NEP requires that assets prove that they exist, before actual transfer.

Example for NEP-5:
transfer myaddress youraddress 100

How much did I have before? zero? 1000? We don't know, unless we process the whole chain at that point (or restore the point with some state trie). This proposal is simple, yet powerful:

Transfer operation NEP-5 (using solid state records):
value = balanceOf myaddress
assert(value == 250) # ok, now I'm sure what my funds were before transfer
transfer myaddress youraddress 100
value2 = balanceOf youraddress
assert(value2 == 600) # ok, now I'm sure what your funds were after transfer

If this transaction passes on chain, we have a evidence for two things: I had 250; and I have transferred 100 to you; and now you have 600.

More elaborate versions of this could require saving previous and after balances, for both addresses, but personally I think that a single "before" register is enough to guarantee quite a few nice properties. For NFT implementations, the count before and after of transferred asset (if countable), or hash state (if hashable); so this is not just intended for NEP-5, but for all onchain assets (not mandatory standard, of course, use it if you like).

Justification:
Neo Blockchain is quite special, in the sense that it doesn't add a solid state reference to block header itself, giving fundamental bugfixing capabilities to the network (that already could have prevented hundreds of hard forks on it). There are many proposals for state tracking on Neo3, in many different formats, however, I believe this proposal here adds much guarantees and auditability to NEP-5 tokens, with or without state tracking. And this is something users (or user wallets) can do for themselves, it's easy and gives strong certainty of instantaneous states on the chain, just by looking at operations themselves.

Drawbacks:
This may not be wanted on situations where several transactions compete to enter a block, in very high throughput operations on same address (like exchanges), as this NEP also fundamentally breaks the possibility of "double-spending" of any kind of token, in any situation. Yet, for common daily transfers it looks quite nice. User wallets could use it to send assets to an exchange, and withdraw operations on that same exchange not necessarily using this (that's why only prev balance is desired, not destination).

Hello,
@lllwvlvwlll suggested that we add the Chain Version in our NEPs.
I think this is a good practice, since if when we update NEO, we may affect NEPs.

We should be able to mark witness VerificationScript by some "standard script" identifier.

Examples:
PUSH signature / Check signature - Standard Verification 1
PUSH signatures / Check multisig - Standard Verification 2
etc

Some time ago (months), we discussed on a similar situation, with @shargon, and he wisely commented that it wouldn't be interesting to have a NEP to inform things that could not be true... I mean, tx submitter may "lie" about which verification format is. In this case, I propose that nodes verify the format, and reject tx if a specific format is declared, but not followed.

Example:
declare multisig, but perform single sig

Positive points: this allows us to do some optimizations, specially for blockchain explorers, as they will better know witnesses intentions, and clearly indicate that (single sig / multi sig / etc).
This is important for this NEP: #102

Negative points: this is an extra byte (if we limit to 255) on all cosigners, unless we manage to keep it optional somehow.

Does the ABI can provide a mark, which can identifies the function whether perform onchain or offchain.

So the dapp developer needn't to care about the the smart contract detail or use which protocal to interact with the blockchain. SDK will use ABI to decided whether query on the node or make a transaction on the blockchain.

Since we now have proper support for checking signatures of arbitrary messages within the NeoVM, should we also have a standard for structured data so that wallets / clients can let users properly examine messages that they are signing in a human-readable way?

See: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md

In the following cases, the client should be able to repair automatically.
1, bug fix
2, seeds server changed
3, version update

Currently NEP-11 only restricts the type of tokenId in that it should be a ByteString, but ByteString can be up to MaxItemSize bytes long which is 1M at the moment. Then NEP-11 tracker (neo-project/neo-modules#671) will create 1M+ long key and store it in the DB. It should work, but likely it'll be quite slow and clients might have issues displaying these long IDs.

The proposal is to set some limit for valid NEP-11 IDs (like MaxStorageKeySize that is 64 bytes at the moment) which will allow clients (and NEP-11 tracker) to ignore invalid ones.

Gas is the power that runs Neo network, which Neo itself is the governance token behind it.

In some situations, community members have expressed their desires of simplifying user operations, e.g., having to buy gas, just to transfer a bunch of Neo... this can happen with any NEP-5, or any asset transfer in fact.

This would require buying these Gas on an exchange, or DEX, but even if it's few cents, this would require several compliance measures, KYC, and in countries like mine (Brazil), user would need to present detailed reports for even few cents operations.

Therefore I believe that creating such an integrated feature would be very helpful to users.

Proposal can be something like this:

• a method for getratio, which will give ratio of that token/asset (NFT, NEP-5, ...), into GAS.
• a method for getgas, which will attach the precise amount of GAS to backup user tx fees.

Note that getgas shouldn't give profit for users, nor any excess, to avoid DEX discussions. This is good for any NEP-5 that implements this NEP-Z, and the only complicated one now is Neo: because it's not fractionary.

Since excess shouldn't come back to users, it would be complicated to spend a single Neo per tx... since Neo already generates Gas, this is more-or-less solved, but if it gets fractional, then it would be able to benefit more from this.

Implementation:

To implement getratio: contract could use embeded Neo oracles, to periodically update gas ratio (ratio could be higher than market, which is good for gas offers, and also for users that get an integrated service)

To implement getgas: execution could read from Sender field, or any other requirement of fees, and authorize transaction upfront (as long as ratio is matched).

To keep flow of gas, listed third-party addresses with funds could be provided on contract, and used to extract funds. A command like registergas could be provided, with some locking mechanism to keep it there for a while.

One interesting point is that this is not a compete approach to DEX, but complementary... it's very likely that DEX would also support some GAS gateways, to back-up their own user operations. As long as this NEP is very simple, we can easily integrate it to native mechanisms of Neo blockchain.

Thanks to @MorganDream @EdgeDLT @vncoelho and many others that kept discussing this important topic in the past months... let's add other issue references here too. Please let's discuss this carefully.

Proposal

Name: NEP-5
Title:Token Standard
Author: luodanwg [email protected], tanyuan [email protected]
Status: Draft
Created: 10 August 2017
Resolution: Proposals
Template: NEO_NEP_5

Abstract

The following describes standard functions a token contract can implement.

Specification

Token
Contracts that work with tokens

Methods

NOTE: The contract developers must implement all function if they want to work with the specified tokens.

TotalSupply

 private static BigInteger TotalSupply()

Get the total token supply

Name

private static string Name()

Get the name of token

Symbol

private static string Symbol()

Get the symbol of token, symbol used to represent a unit of token

Decimals

private static BigInteger Decimals()

Get decimals of token

BalanceOf

private static BigInteger BalanceOf(object[] args) 

Get the account balance of another account with address which is first element of args and type is byte[]

Transfer

private static bool Transfer(object[] args) 

function that is always called when someone wants to transfer tokens. The first element is sender address and type is byte[], the second element is receiver address and type is byte[], the third element is the number of token and type is BigInteger .

Event

Transferred

private static void Transferred(object[] args)

Triggered when tokens are transferred. args is the same with transfer.

Now that we have Refuel mechanism, I propose that we discuss some NEP for Sponsored Operations, with the following operation:

• sponsorValue(string methodName, object[] args, Hash160 sender) -> BigInteger "GAS"

With this operation, a deployed contract may inform user, aka "sender", its willingness to sponsor some GAS during execution time for the intended operation methodName.

Example:
Some NEP-17 implements this NEP and provides that "transfer" gives extra 0.5 GAS for the user. This check can be done during test time (as a "const" operation), and then, User Wallet then should be able to estimate how much GAS it needs to reach the point of method invocation, including sponsorValue GAS cost. On the other hand, contract that implements this NEP, should use sponsorValue as the first operation in the method, and should throw exception if not willing to provide GAS (so, "transfer" tests, such as balance check, could be put inside sponsorValue, thus being paid by the user together with network/tx fees).

After global assets are abolished, some people may want to keep UTXO behavior on their tokens. Perhaps we can start creating a standard for that.

In my opinion, it could be nearly the same as NEP-5 (including a consolidated balance), but with minor differences on transfer function (including unspent inputs and multiple outputs).
That won't be very challenging to implement I think.