axentro / axentro Goto Github PK

Implement infrastructure to allow developers to build Dapps on SushiCoin in a similar way to Ethereum or Neo

Most coins don't require you to enter connection information every time you run the daemon. Instead all of that info is stored in a ~/.coinname/coinname.config file. I propose that we come up with a configuration file structure that will allow us to list node connection information, privacy settings for our node, default wallet location, etc.

Currently, all nodes connect to all nodes.
Must rethink about this.

Update the wiki and any other documentation to reflect the recent changes in the code

When I start a sushid and give it a connecting node behind apache - it's not syncing from the connecting node:

It's connected to the node in the above view - but fetching wallet amount from testnet and from local node give different results:

If I start sushid directly against the port on the testnet - it does sync correctly:

So I think the problem is with the apache forwarding on the testnet AWS - I'm going to change this and put a LB in front of the sushid server and remove apache proxy and instead get the LB to forward the ports.

SushiChain Address Resolution System (SCARS)

Provide human readable identifiers for blockchain addresses. Similar how a domain name points to an IP address.

So you can send and receive coins/tokens to an address using the human readable name which is also much easier to remember and handle.

A user can register their address to a name - as long as the name is not taken already. To avoid confusion only one name can be registered to an address.

e.g. S0M3SUSH1ADDR3SS => kingsley.sushi

I think this could be implemented as a DAPP on top of SushiChain.

See the Ethereum one for reference: http://ens.readthedocs.io/en/latest/introduction.html

move to yescrypt to prevent mining on GPU/ASIC

provide at least 1 non Crystal Wallet.

I've done most of the ground work for a Javascript based Wallet. The Elm language is my strong point - so thinking of creating an Electron or Web wallet using Elm.

In order to support the wallet we could add some extra commands to sushi so that a user can query useful information:

Get all transactions for an address

The user can use this info to check what was send and received from their address.

Multisignature (multisig) refers to requiring more than one key to authorize a transaction. It is generally used to divide up responsibility for possession of coins.

https://en.bitcoin.it/wiki/Multisignature

nodejs is one of the choices since it can be used in many platform.

other options are

• Java for Android
• Swift for iOS

🤔

Integration test should contain following tests/results

• Launch multiple nodes. These nodes have same blockchain.
• Show how many transactions do the nodes accept? [transaction/sec]

<W(rite) IP>

Developable blockchain is attractive especially for developers.

About block

• Get whole blockchain
  • header only (without transactions)
• Get a block by block index
• Get blockchain's length

About transaction

• Get transactions in a block
• Get a block by transaction's id
• Post a new transaction

About utxo

• Get remaining amounts of the specified address
  • include unconfirmed amounts or not

There is no reason for using floating number as a amount of coins.
It may make bugs at some point. So it should be integer.

• User can create a node behind a NAT.
• --private flag instead of '-u'

The way the rpc controller works currently all of the commands are stored in one controller. This works of for the small amount of commands that exist currently, but as more methods are added the controller is going to become quite bloated.

I propose that we allow the rpc_controller to be changed into more of an rpc_router which routes commands to the appropriate controller. The controllers would each define the arguments and flags they take, their description, command signature, etc. In this way the cli would only have to have cli specific commands, and if the cli is connected to a node it can list the commands that the node accepts as well.

The following is what I'd imagine an RpcCommand looking like:

module ::Sushi::Core::Controllers
  abstract class RpcCommand
    include ArgParser

    abstract def call(json, context, params)

  end

  class CreateUnsignedTransaction < RpcCommand

    command_name "createunsignedtransaction"
    
    argument sample : String,
      required: true

    flag debug : Bool,
      short: "-d"

    def call(json, context, params)
      action = json["action"].to_s
      senders = Models::Senders.from_json(json["senders"].to_s)
      recipients = Models::Recipients.from_json(json["recipients"].to_s)
      message = json["message"].to_s

      transaction = @blockchain.create_unsigned_transaction(
        action,
        senders,
        recipients,
        message,
      )

      fee = transaction.calculate_fee

      raise "Invalid fee #{fee} for the action #{action}" if fee <= 0.0

      context.response.print transaction.to_json
      context
    end

  end
end

Use github wiki for details.

For users

• What is Garnet?
• How to build it?
• Create a wallet.
• Run a node.
• Start mining process.
• Send Garnet coins to others.
• Confirm remaining amounts of coins for a wallet (address).

For blockchain lovers

• What's difference between Garnet and other blockchains.
• Garnet's consensus algorithm
• When the Garnet will be released?

For developers (Not implemented yet)

• API
  • about blockchain
  • about transaction

I’ve been thinking about features:

It's annoying when someone hacks you and steals your coins by using the stolen private key - one possible solution is to use two factor auth when sending a coin - but in other blockchains this doesn’t work because as long as you have a private key you can go to any web wallet so the attacker picks one with the least security

But if there was a way to optionally turn on 2fa for your address in the blockchain itself - this would solve this issue

So you could choose to turn it on and then a node won’t accept a transaction unless the 2fa code is provided.

To turn it on you just provide your wallet and choose to use 2FA and then you get a QR code to scan in to authy/google authenticator and then you are asked to verify by entering the next code and thats it. (along with the QR code you get the numerical version so you an back it up - and on the command line we can just give the numerical instead of the QR code)

To turn it off - you pass through the 2FA again then it turns off.

When turned on you have to provide the 2FA code when you send a transaction to a node.

This could be implemented as a built in dApp in the same way scars or uxto works

Please discuss what we need for it here.
You can update this comment if you need.

> @watzon Personally I'd like to throw everything we have at this. The main page could just be a splash page with information about sushi coin, and then we can have a blog or we post updates, and then we can have a block Explorer and wallet generator

> @kingsleyh
most of the sites have a few things in common - they have

1. whitepaper
2. info about the developers who are building it
3. info about how to get the wallet and get started
4. some contact info

References (from slack discussion)

• https://garlicoin.io/
• https://saltlending.com/

In order to support the wallet we could add some extra commands to sushi so that a user can query useful information:

get number of confirmations for a transaction

e.g. 1/10

so a user can check to see when the transaction has been fully completed and any coins send or received can be used.

If 1 coin is worth £1000 and I want to send only $10 worth of coin to an address we could perhaps follow a similar strategy to Ethereum:

https://steemit.com/cryptocurrency/@encryptcy/ethereum-denominations

It would be nice to have a gitter, telegram, discord, or slack channel where we can discuss the development of this. I love Crystal, I also love Sushi, and I love the idea of bringing more exposure to Crystal through crypto currencies. I'd be very interested in helping with this project, but we need a place that devs and potential devs can chat.

I cannot connect my node to another node with --node= or -n

It says the node is standalone

blockchain -> bc
transaction -> tx
transactions -> txs
wallet -> wt

and so on.

It's not a critical but is needed.
Also, should be through some CI. (I prefer travis.)

Currently all chains are stored on memory.

Blockchain should use a database for 2 aspects;

• Cache: Not necessary to get whole chain when restart a node process
• Fault Tolerance: Enable to restore the chain even when all node process gonna be down.

Currently, cheep PoW is implemented.
Should rethink about it.

A (Short) Guide to Blockchain Consensus Protocols
https://www.coindesk.com/short-guide-blockchain-consensus-protocols/

We can create a blacklist for it.

When do handshake with nodes, the node should check the public address is valid or not.

Currently, it's fixed as 10.0
https://github.com/tbrand/Garnet/blob/master/src/core/blockchain.cr#L147

Should be decrease according to block height like bitcoin.

Here are a few node issues which happened when running - not sure why they happened yet. But tracking them here so we can fix.

1. Closed stream and invalid nonce on standalone node (when only running 1 miner with 2 nodes started up (1 standalone, 2 connected to standalone)

2. Unhandled exception (I think this happened on the standalone node when a node connected to it was stopped)

Abstract

Currently sushid supports --conn_max=CONN_MAX option that decides first number of connections. The node will accept additional connections, so the name is wrong. It should be --conn_min. (minimum number of connections)

AC

If a remote node is disconnected and total number of connections is less than the --conn_min=CONN_MIN, the node should try to find another node to be connected to guarantee the minimum number of the connections.

Tasks

• Rename --conn_max=CONN_MAX to --conn_min=CONN_MIN
• Try to find another node to be connected if total number of connections is less than the specified number after some node has been disconnected.
  • Add a protocol to request a node_list

Instead of only accepting text/plain with json as an escaped string - we should accept application/json with a json body.

Currently despite setting the CORS header on sushid - it reject everything except text/plain - I think this is because the payload is actually text/string and not json body.

In order to run the testnet as https - the miners must make an SSL connection to the testnet - and also sushid must be able to start in SSL mode with the certs (like Kemal does)

>./sushi wallet amount -w wallet1.json -n http://localhost:3000

show Sushi coins amount of 
VDAwYTUwYjllNmNiNGE3YjMxYjE3ZmVjZTk1Njg4MzM0ODM5MDA4ZTY4ZjdlZTNh
0

./sushi tx send -n http://localhost:3000 -w wallet1.json -a VDAxYmIwNWIyOTFlNGY3ZDViOTliY2UyNTE0MTI5MmVjMTI3NGI5OTZhNzhkZmY1 -m 1

successfully create your transaction!
=> 6fda20462a3587c062099bfd83aec9b8039091840a7526aa780a52bc385d8e3c

I guess this transaction would hopefully be rejected eventually (after mining) because of having no coins in the wallet - but it would be nice to reject the send right away if there are not enough coins at that point in time (if we are able to know this information)

currently, calculating fees are done during the runtime. but it should be cached into transactions for a performance optimization.

Twitter integrated rewards is very effective for the promotion.

• RT our tweet -> 1 SushiCoin
• Send SushiCoins a.k.a. tips.
• Create wallet.
  and so on.

These are many things to be discussed. (How to integrate? How to manage secret keys? and so on.)
But I want to keep this open as just one of the idea.

Content

If the difficulty is updated, easier blocks will be invalid currently.
So have to record the difficulty onto each block.

Todo

• pass the difficulty to sushid.
• difficulty in blocks
• send node_lists for broadcasting

When user search their transactions by transaction id and if the transaction was rejected, there is no way to know why the transactions was rejected now.
So we should record the transactions with the reasons.

Content

User of SushiCoin can create original token on it's blockchain.

change wallet format to include wif and single public key
wallet to create encrypted wallet with password

For who don't have a crystal environment.

https://github.com/SushiCoinHQ/SushiCoin/blob/master/src/core/blockchain.cr#L189
https://github.com/SushiCoinHQ/SushiCoin/blob/master/src/core/blockchain/block.cr#L98

Currently, fees are automatically added into a transaction.
Senders have to specify fees to prevent it.

Testnet is necessary especially for new comer or developers.

Tasks

• check when handshake
  • with another node
  • with another miner
• healthcheck
• check network type when create transaction

I started a miner with the following command a few times, and after that the local node started to give an error.

./sushim -w testnet-wallet.json --testnet -n http://54.199.249.171:3000 --threads 2

Error:

$ ./sushid -w testnet-wallet.json --testnet -n http://54.199.249.171:3000 --private
[ 2018-01-26 14:41:47 --    Info ] id: 05e751d304308996f98c5443da7018ae
[ 2018-01-26 14:41:47 --    Info ] is_private: true
[ 2018-01-26 14:41:47 --    Info ] loaded blockchain's size: 1
[ 2018-01-26 14:41:47 -- Warning ] no database has been specified
[ 2018-01-26 14:41:47 --    Info ] connecting to 54.199.249.171:3000
[ 2018-01-26 14:41:48 --    Info ] start running Sushi's node on 0.0.0.0:3000
[ 2018-01-26 14:41:48 --    Info ] network type: testnet
[ 2018-01-26 14:41:49 --    Info ] successfully connected: f7c1ccd43cab074b60beefc0c180416b (1)
[ 2018-01-26 14:41:51 --    Info ] recieved chain's size: 209
[ 2018-01-26 14:41:57 --   Error ] Invalid merkle tree root: 59977fbe757151d21fefb324f40e56e5c6c08e19 != 23a04f3e4afda59306c3db11478c2d928f5eb01f
[ 2018-01-26 14:41:57 --   Error ] on: 54.199.249.171:3000

So we can generate a wallet anywhere e.g in javascript on the GUI client as well as in other languages