goat-systems / go-tezos Goto Github PK

Throughout the code, there are many "level / 4096" for calculations based on cycle. Alphanet uses 2048 blocks per cycle. If this were changed to a global CONST then a simple adjustment is all that is necessary to make code work on alphanet. Or even changing to a global variable and having a -alphanet switch.

Can only use this function with currently relevant data. Need to make it work historically.

Currently the go-tezos delegation functions are unreadable, and need cleaned up and simplified.

Just pulled latest master and tried rebuilding my program:

$ go build -v
blockwatch.go:8:2: no Go files in /home/baking/go/src/github.com/DefinitelyNotAGoat/go-tezos
../github.com/DefinitelyNotAGoat/go-tezos/client/client.go:13:2: cannot find package "github.com/pkg/errors" in any of:
	/usr/local/go/src/github.com/pkg/errors (from $GOROOT)
	/home/baking/go/src/github.com/pkg/errors (from $GOPATH)

We should dynamically allocate the number of works needed based of the delegate's size. The tezos node can't handle large delegates, with the amount of workers that's default.

It's including contracts in Cycles they aren't snapshot(ed) in. It will include people in the wrong snapshots when querying with the -cycles flag, but not the -cycle flag.

How do I use an existing wallet to send payouts? Or, what is a more secure way of creating a new wallet other than modifying the core library code?

goTezos relies on the tezos-client binary. And it's not always fast, especially when doing many requests at once. Figure out a way to improve the underlying querying, probably through a database synchronized with the network.

Figure out the timestamps of a delegated contract, so you can sort a group of delegated contracts by age.

Change file names to Go Standard, comment all exported functions.

rtrade@tezos1-zeronet:~/go/src/github.com/DefinitelyNotAGoat/goTezos/ExampleTools/delegationPayout$ ./delegatePayout  -delegateaddr tz1bhL4zwmLJvHJK5ejDDKdeatpqorvJdc2s -cycle 13 -payout=true
Taco Mission 5 / 5 [===============================================================================================================================================] 100.00% 18s
Tacos Have Been Made On This Day!

No indication on tzscan that a reward has been paid:
http://alphanet.tzscan.io/tz1bhL4zwmLJvHJK5ejDDKdeatpqorvJdc2s

Go version:

go version go1.10.3 linux/amd64

When i try to use go-tezos as a library in another go programm, i get:

[] Error loading .env file: open .env: no such file or directory

when constructing with:

ngt,err := gotezos.NewGoTezos("http://" + e.Tezos.Container.Ips[0]+":8732",)

this is caused by:

4f80fbc

this makes no sense to me, why is the URL parameter ...string when multiple urls are not even used,

if i construct with

ngt,err := gotezos.NewGoTezos("http://" + e.Tezos.Container.Ips[0]+":8732","nowthisworks")

if works obviously, because URL[0] now returns the entire address, whereas before it would evaluate to "h" which does not have length > 1 and force it to laod a .env file.

Hey @utdrmac -

Maybe we should consider how we handle network versions differently. Depending on what gateway your hitting for this, it seems a lot of them have this method closed, and it causes the program to exit. It works fine for people using go-tezos with a node that doesn't have limitations, but we should probably account for that somehow?

The sub-services in Go Tezos have a reference the their parent Go Tezos struct, instead they should just have a reference to the client, and the specific services they depend on.

Calculate payments should have a minimum parameter, to only return payments greater than a certain threshold in mutez.

Add a logger that logs errors and debug messages for the library.

Throughout the code certain functions are called which check for errors. If an error exists a message is printed to the console, but not the actual error itself.

An example from delegatePayout.go

  if (err != nil){
    fmt.Println("Invalid Delegator Address " + *delegateAddr)
    os.Exit(1)
  }

How it should be:

  if (err != nil){
    fmt.Println("Invalid Delegator Address " + *delegateAddr)
    fmt.Println(err)
    os.Exit(1)
  }

In my opinion is important that all kind of results share the same unit, there are currently some functions that return values in mutez and others that return in tez.

For consistency purposes all functions should return the values in mutez, leaving the conversion part for the user. ( Helper functions should be implemented so the user can convert between units ).

This change should be included in the next major release.

• Change the functions to return mutez instead of tez;
• Implement helper functions to convert between units.

This is a documentation contribution "issue". When you use the alphanet faucet (for testing), the .json contains the 15 mnemonic words, a password, and email address. If you want to import this address using CreateWallet, the "password" is actually the email and password concatenated together.

Example:

mnemonic := "normal dash crumble neutral reflect parrot know stairs culture fault check whale flock dog scout"
email := "[email protected]"
password := "PYh8nXDQLB"
bakerWallet, err := gt.CreateWallet(mnemonic, email+password)
fmt.Println("- Address:", bakerWallet.Address) -- tz1Qny7jVMGiwRrP9FikRK95jTNbJcffTpx1

When using this function to create a new wallet, you can use whatever you'd like as the password. There are no restrictions on requiring an email address to be part of the password.

When forging an operation in operations.go, we are not checking the response from the node for correctness. This could be potentially hazardous and cause someone to sign a malicious response from an untrusted node.

I'm attempting to create a new operation, sign it, preapply it, then inject it. The error I'm getting is proto.004-Pt24m4xi.baking.unexpected_endorsement. This error indicates the signature is for a different address. I've verified many different ways that the wallet was imported correctly so I know that is not the issue.

I believe the issue lies within the decodeSignature operation. When attempting to compare the execution of the various steps within GT library vs using tezos-client, I get different lengths of returned decoded signature.

Forged Operation Result: 39ad83c1e08b9f6710373469f3435a34fb29572cac027069689d9940d1dc8f9d00000a23a8
GT Signature: edsigttdVRhuar9KdWb25JNttdHXPJEftVCFH4GLZVmFM41yPhEPYGfSJmefuhrVGEPzhShjYkj1hwJqzD73bKkvcrS9B6VXWmN
Client Sign Bytes:

./tezos-client sign bytes 0x0339ad83c1e08b9f6710373469f3435a34fb29572cac027069689d9940d1dc8f9d00000a23a8 for burrito1
Signature: edsigttdVRhuar9KdWb25JNttdHXPJEftVCFH4GLZVmFM41yPhEPYGfSJmefuhrVGEPzhShjYkj1hwJqzD73bKkvcrS9B6VXWmN

Signatures match between GT lib and tezos-client.

Using the example posted here, I decoded the signature using python:

$ python3
Python 3.6.8 (default, Aug 20 2019, 17:12:48)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import base58check
>>> base58check.b58decode(b'edsigttdVRhuar9KdWb25JNttdHXPJEftVCFH4GLZVmFM41yPhEPYGfSJmefuhrVGEPzhShjYkj1hwJqzD73bKkvcrS9B6VXWmN').hex()
'09f5cd86129f29700caef6afc214dadd3ef5d98efd0ec38b74edc7ac9c623ff912154fa4208e4ec15e7798369cadd2139f9cea02f3f54ac22f7b9fc27faa348248aad3b403abe0db31'

Compare the above output to the string returned by gt.Operation.DecodeSignature(edsig): 09f5cd86129f29700caef6afc214dadd3ef5d98efd0ec38b74edc7ac9c623ff912154fa4208e4ec15e7798369cadd2139f9cea02f3f54ac22f7b9fc27faa348248aad3b403

Notice that the python decoded signature is 8 characters longer than returned by GT lib. abe0db31 is missing from GT lib version.

Somewhere in GT crypto.Decode() there's an issue with not returning the entire decoded hex-string.

If entering bad information, or wrong format the program will crash.

The "Getting A Block" example code at https://github.com/DefinitelyNotAGoat/go-tezos will not compile as is. It seems to be copy-pasted from test code (t.Errorf for example)

I think this package should also support stream requests to the node rpc, like monitor/heads/<chain_id>.

I have implemented this in my block explorer, could clean it and open a pull request if you agree with adding this feature.

As far as i can see this does not expose the peers of the connected node.

This project should really move away from using wrappers for the libsodium C library, and just use the the standard crypto lib from go

I have the following code:

gt, err := goTezos.NewGoTezos("http://127.0.0.1:8732")
if err != nil {
	fmt.Printf("could not connect to network: %v", err)
}

block, err := gt.Block.Get(1000)

It crashes with this log output:

could not connect to network: Error loading .env file: open .env: no such file or directory

Stack trace:

anic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x13be9d5]

goroutine 1 [running]:
github.com/DefinitelyNotAGoat/go-tezos.(*BlockService).Get(0x0, 0x140f1c0, 0x15382f0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/Users/sam/go/pkg/mod/github.com/!definitely!not!a!goat/[email protected]/block.go:180 +0xe5

"rewards" are string type. Why? Shouldn't they be int?

In the app I'm writing, you create payments, sign them with the wallet, and then call goTezos.PostResponse to /injection/operation This usually returns immediately, indicating that your op was accepted by the node to which you are connected. But the return does not mean it has been processed by the network. You have to wait, at minimum, for the current block to complete, or in the future when there are many more transactions per block, you may need to wait several blocks.

The tezos-client provides wait for <op> to be included, which does the following:

• grab the previous 10 blocks, look for op hash
• if not found, look at head
• sleep some amount of time, fetch head, repeat until found
• if you specify --confirmations N, sleep-head-repeat until N confirmations

#35 supports fetching block operation hashs. After/When/If merged, what is the best way to "poll" looking for ops using goTezos?

Here is a function that I was considering adding to goTezosBlock.go:
https://gist.github.com/utdrmac/74e00b6c722dcbd3dffd9e7961a00b33

Thoughts on this? Should this be added to goTezos or should this type of implementation be left up to the caller and just utilize #35?

Make options available for users to choose which API they use, or if they want to make read request local only.

Clean up the code to use a single logging function that does all the associated logic inside of it.

Older snapshots can't be retrieved from the head, there needs to be block math to get the hash for which to query.

Support the tezos RPC crypto side.

snap.AssociatedBlock = ((cycle - 7) * 4096) + (snapShotQuery.RollSnapShot + 1) * 256

Requesting cycle < 7 produces negative values and always returns the genesis block

On Alphanet,

Calling GetAccountBalanceAtSnapshot() with any address at cycle 1 gives me the following panic. Cycle 0 and cycle 2 also gives me this error, just not consistently. Might be related to caching?

/usr/local/go/src/runtime/panic.go:513 +0x1b9
github.com/DefinitelyNotAGoat/goTezos.(*GoTezos).GetBlockAtLevel(0xc00009eea0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
src/github.com/DefinitelyNotAGoat/goTezos/goTezosBlock.go:224 +0x73d
github.com/DefinitelyNotAGoat/goTezos.(*GoTezos).GetBlockHashAtLevel(0xc00009eea0, 0x1, 0x1, 0x0, 0xc00024e600, 0x33)
src/github.com/DefinitelyNotAGoat/goTezos/goTezosBlock.go:206 +0x72
github.com/DefinitelyNotAGoat/goTezos.(*GoTezos).GetAccountBalanceAtSnapshot(0xc00009eea0, 0xc0000cc021, 0x24, 0x1, 0x0, 0x71c420, 0x6c1c01)
/root/work/src/github.com/DefinitelyNotAGoat/goTezos/goTezosBlock.go:356 +0xee
main.getAccountBalanceAtSnapshot(0x789aa0, 0xc0001041c0, 0xc0001f6600)
...
http panic serving 127.0.0.1:46588: interface conversion: interface {} is goTezos.SnapShot, not goTezos.Block

(I'm returning the result via an HTTP API)

Wrong share percentage calculated.

Need to create on going unit tests.

Calling CreateBatchPayment() leads to calling forgeOperationBytes() which calls client.GetReponse() https://github.com/DefinitelyNotAGoat/go-tezos/blob/66b1b13b64b1c78053a391c495c0d97c6a70e16f/goTezosNode.go#L44

This is a POST operation, not a GET, therefore the call fails.

$ ~/tezos/tezos-client rpc list /chains/main/blocks/head/helpers/forge/operations

Available services:

  - POST /chains/main/blocks/head/helpers/forge/operations
      Forge an operation

A good suggestion from Johann in the Tezos Community.

This function pulls snapshot info from cycle 7 to current. I'm wondering if this should be adjusted to only retrieve the most recent $preservedCycles snapshots? https://gitlab.com/tezos/tezos/merge_requests/720 will soon be reality. The patch currently only keeps $preservedCycles in local node database. Thus, when you call GetAllCurrentSnapShots and RPC tries to fetch data on a block that doesn't exist, the function errors and immediately returns.

Option 1) adjust the function to "return all" but instead of error on 'snapshot not found', returns empty values in snapShotArray
Option 2) change the for-loop to only return currentCycle - this.Constants.PreservedCycles snapshots

Thoughts?

If you call GetDelegateAtBlock(), and there is no delegate set, the URL/RPC fetched returns HTTP 404 Not Found. This results in an error returned to the caller. It would be better if this simply returned "none" rather than error.
Possible solution is to parse and return the object fetched without '/delegate'

{
  "manager": "dn1fJ9gJnEQaPZMitcdWi8FDY18RzNXwESAk",
  "balance": "1899561451",
  "spendable": true,
  "delegate": {
    "setable": true
  },
  "counter": "0"
}
vs.
{
  "manager": "dn1fJ9gJnEQaPZMitcdWi8FDY18RzNXwESAk",
  "balance": "1899558762",
  "spendable": true,
  "delegate": {
    "setable": true,
    "value": "dn1HmyR4WEGPzbUbbKbgbqo48ENE7n2h3Jww"
  },
  "counter": "2"
}

There are a few duplicate functions that achieve the same goal that need to be removed. As well as cleaning up any vendors that need it.