what does this involve?

Currently in case of crash during account configuration, the process will not be resumed after restart.

SubmitTransaction is returning: "decode response failed: Horizon error"
This isn't helpful. It should have the full response from horizon so I can figure out what is going wrong.

@poliha's horizon is stuck because of this error:

time="2017-10-18T10:22:32Z" level=error msg="import session failed: failed to exec sql: exec failed: pq: new row for relation "history_trades" violates check constraint "history_trades_sold_amount_check"" pid=1267

It looks like horizon is unable to process operation: 60415642800492545 because one of it's effects violates history_trades_sold_amount_check constraint on history_trades table:

CONSTRAINT history_trades_sold_amount_check CHECK ((sold_amount > 0))

I don't see how to retrieve the values from the Managed Data section of an Account object.

After executing the SetData(key_string, value_bytes) operation on an Account (which succeeds) I expected to see something like Account.GetData(key_string) or Account.ManagedData[key_string] on the object that comes back from Client.LoadAccount(account_id).

The Horizon server includes the values in the data field on the Account's JSON response object.
You can see an example on Account GCORTO4MOGRSOZOVYELTL5SDTZCGLE2YA7YDYV7X5EMDTHARSMEAOZJQ in the Test Network here:
https://www.stellar.org/laboratory/#explorer?resource=accounts&endpoint=single&values=eyJhY2NvdW50X2lkIjoiR0NPUlRPNE1PR1JTT1pPVllFTFRMNVNEVFpDR0xFMllBN1lEWVY3WDVFTURUSEFSU01FQU9aSlEifQ%3D%3D&network=test

Here's a trimmed version of the full response:

{
  "_links": {
 ...
  },
  "id": "GCORTO4MOGRSOZOVYELTL5SDTZCGLE2YA7YDYV7X5EMDTHARSMEAOZJQ",
  "paging_token": "",
  "account_id": "GCORTO4MOGRSOZOVYELTL5SDTZCGLE2YA7YDYV7X5EMDTHARSMEAOZJQ",
  "sequence": "993559079550998",
  "subentry_count": 5,
  "thresholds": {
    "low_threshold": 0,
    "med_threshold": 0,
    "high_threshold": 0
  },
  "flags": {
    "auth_required": false,
    "auth_revocable": false
  },
  "balances": [
...
  ],
  "signers": [
...
  ],
  "data": {
    "..": "R0NCVkwzU1FGRVZLUkxQNkFKNDdVS0tXWUVCWTQ1V0hBSkhDRVpLVldNVEdNQ1Q0SDROS1FZTEg=",
    "SecondString": "R0NCVkwzU1FGRVZLUkxQNkFKNDdVS0tXWUVCWTQ1V0hBSkhDRVpLVldNVEdNQ1Q0SDROS1FZTEg="
  }
}

I also looked at the JavaScript SDK to see if I could figure out the expected pattern but data retrieval Operations seems to be missing from there as well (but perhaps the JSON response object loads more natively in that SDK).

• copy stellar/horizon -> stellar/go/services/horizon
• deal with the dependencies (GB -> go build)
• change stellar/docs, stellar/developers to point to the new horizon url
• update stellar/horizon with a "repository has moved" message
• merge any changes made to stellar/horizon during the port (1 change)
• update the documentation how to build horizon
• horizon tests to use Postgres() for parallelization (remove horizon script from .travis.yml)

As described in design doc.

• Recovery transactions

so people can stream various things from a particular point in time

Withing the build package change methods with arguments of type interface{} to something more appropriate and descriptive.

for our internal dashboards

services/horizon/db2/page_query.go:171: constant 9223372036854775807 overflows int

page_query.go:171

I noticed this in Travis failed job. Also looks like Travis runs before_deploy but it shouldn't (probably Travis bug).

We should also check how this passed tests in #93 and fix our test script.

The code examples on: https://www.stellar.org/developers/guides/get-started/create-account.html are broken.

Let's take the first one as an example:

package main

import (
	"log"

	"github.com/stellar/go/keypair"
)

func main() {
	pair, err := keypair.Random()
	if err != nil {
		log.Fatal(err)
	}

	log.Println(pair.secret())
	// SAV76USXIJOBMEQXPANUOQM6F5LIOTLPDIDVRJBFFE2MDJXG24TAPUU7
	log.Println(pair.Address())
	// GCFXHS4GXL6BVUCXBWXGTITROWLVYXQKQLF4YH5O5JT3YZXCYPAFBJZB
}

I don't think it has ever worked as pair.secret is not an exposed method. On top of that there's no function anymore called secret. pair.Seed() maybe?

The second example has broken imports (http which should be net/http) and expects code from the first example (pair.Address()) to be present. At last fmt.Println(body) does not make much sense. Maybe a fmt.Println(string(body)) would suffice here.
I suggest either remove the imports and main? or show a fully working example?

I haven't ran more examples through yet, but i have a feeling there's more broken stuff.

Besides, adding comments to exposed methods/functions is always a nice bonus ;-)

➜  github.com/stellar/go/keypair git:(master) ✗ golint
from_address.go:19:1: exported method FromAddress.Address should have comment or be unexported
from_address.go:23:1: exported method FromAddress.Hint should have comment or be unexported
from_address.go:28:1: exported method FromAddress.Verify should have comment or be unexported
from_address.go:42:1: exported method FromAddress.Sign should have comment or be unexported
from_address.go:46:1: exported method FromAddress.SignDecorated should have comment or be unexported
full.go:11:6: exported type Full should have comment or be unexported
full.go:15:1: exported method Full.Address should have comment or be unexported
full.go:19:1: exported method Full.Hint should have comment or be unexported
full.go:24:1: exported method Full.Seed should have comment or be unexported
full.go:28:1: exported method Full.Verify should have comment or be unexported
full.go:42:1: exported method Full.Sign should have comment or be unexported
full.go:47:1: exported method Full.SignDecorated should have comment or be unexported

About the lint messages, i could do a pull request on that, once i have read up a bit more on the stellar documentation :)

Federation service throws error and doesn't start if I don't provide reverse federation query

ERRO[0000] config file: invalid fields: ReverseFederation  pid=14273

In address association table, mark successful payments to make finding non-empty addresses easier.

select a pair you are interested in and returns the HLOC+V for the last 24 hours

In #33 user mistakenly entered certificate_file instead of certificate-file in federation server config file. We should probably print a notice to the log if the port is equal to 443 but no certificate files have been specified.

Here is example with ledger-00378d7f.xdr.gz missing on core_live_003:

wget http://history.stellar.org/prd/core-live/core_live_003/ledger/00/37/8d/ledger-00378d7f.xdr.gz
--2017-08-25 12:25:43--  http://history.stellar.org/prd/core-live/core_live_003/ledger/00/37/8d/ledger-00378d7f.xdr.gz
Resolving history.stellar.org (history.stellar.org)... 52.218.16.98
Connecting to history.stellar.org (history.stellar.org)|52.218.16.98|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-08-25 12:25:44 ERROR 404: Not Found.

stellar-archivist does not catch this error

./stellar-archivist --low 3600000 --high 3700000 scan --verify --thorough http://history.stellar.org/prd/core-live/core_live_003/
2017/08/25 12:23:23 Scanning checkpoint files in range: [0x0036ee3f, 0x0038753f]
2017/08/25 12:23:35 Archive: 1564 history, 1564 ledger, 968 transactions, 0 results, 0 scp
2017/08/25 12:23:55 Checkpoint files scanned with 0 errors
2017/08/25 12:23:55 Archive: 1564 history, 1564 ledger, 1564 transactions, 1564 results, 1564 scp
2017/08/25 12:24:01 Archive: 312 buckets total, 312 referenced
2017/08/25 12:24:01 Examining checkpoint files for gaps
2017/08/25 12:24:01 Examining buckets referenced by checkpoints
2017/08/25 12:24:01 No checkpoint files missing in range [0x0036ee3f, 0x0038753f]
2017/08/25 12:24:01 No missing buckets referenced in range [0x0036ee3f, 0x0038753f]
2017/08/25 12:24:01 Error: mismatched hash on ledger header 0x0037983f: expected 214bba8213a2e58e3e40ba1ff57882306b97c305404c5f5d2506917be56e48cf, got 0000000000000000000000000000000000000000000000000000000000000000
2017/08/25 12:24:01 Error: 1 ledger headers (of 63168 checked) have unexpected hashes
2017/08/25 12:24:01 Verified 63168 transaction sets have expected hashes
2017/08/25 12:24:01 Verified 63168 transaction result sets have expected hashes
2017/08/25 12:24:01 Verified 312 buckets have expected hashes
2017/08/25 12:24:01 Detected 1 objects with unexpected hashes

As a beginning, and to help with this issue: #103. Maybe we should start with a simple compact history_assets table that will serve as a lookup table, something like this:

CREATE TABLE history_assets (
  id SERIAL PRIMARY KEY ,
  asset_type VARCHAR(64) NOT NULL,
  asset_code VARCHAR(12) NOT NULL,
  asset_issuer VARCHAR(56) NOT NULL,
  UNIQUE(asset_type, asset_code, asset_issuer)
);

now there is
build.Asset
and
horizon.Asset

Send recovery transactions in case user's keys are lost, as described in design doc.

• Backend
• Frontend

I bought an SSL, key is one I generate using openssl, and crt is downloaded from CA:

I generated using a password.

certificate-file = "mm_hhprint_com.crt"
private-key-file = "mm.hhprint.com.key"

but I got this:

level=error msg="failed to start server: tls: failed to parse private key" pid=14328

Am I missing out something?

Even though I specify TLS certificates in the config it still starts insecure.

This is theoretical attack but should be discussed and at least mentioned in a README file.

BIP-32 allows generating up to 2,147,483,648 - 1 addresses using a single public master key. In theory, someone could send lots of requests and generates lots of unused addresses.

Possible solutions:

• Use m / purpose' / coin_type' derivation path and generate a new account when address_index level becomes exhausted.
• Rate limiting (implemented in bifrost?)
• Captcha (implemented in bifrost?)

StreamEffectsRange
StreamTransactionsRange
etc
would allow you to fetch all the resources between two points. Useful if you want to calculate daily volume for example.

https://godoc.org/github.com/stellar/go/clients/horizon

Moving this discussion here.
To serve StellarTerm and other exchanges, Horizon will expose an API to access aggregated historical information on trades.

Request params:

• base_asset_issuer
• base_asset_type
• base_asset_code
• counter_asset_issuer
• counter_asset_type
• counter_asset_code
• start_timestamp
• end_timestamp
• resolution

Inspired by other exchanges, the available resolutions would be: 5-mins, 10-min, 30-min, 2-hr, 4-hr, 1-day. (anymore?)

The return value would contain an array of records.

Record fields:

• timestamp
• open
• close
• high
• low
• base_volume
• counter_volume
• trade_count

Developers should be able to check if bifrost generates correct public keys using a given master public key. Developers should check if they have corresponding private keys.

In preparation for #94, modifying the history_trades table can assist in simpler aggregation.
The main two issues to handle:

1. history_trades has no time of creation, only operation id. This requires joining with the history_ledgers to get exact times.
2. The separation of buyers and sellers is not relevant for aggregation and forces every query to handle both possible directions.

• Load horizon root endpoint and check if network passphrase is the same as in the config file.
• Load the last ledger close time to check if it's synchronised.

There is a bug in go-xdr (I wasn't able to create an issue there) when trying to unmarshal variable-length array without specified size. Take a look at this union:

union StellarMessage switch (MessageType type)
{
  // ...

case GET_PEERS:
    void;
case PEERS:
    PeerAddress peers<>;

  // ...
}

We can create a special StellarMessage that looks like:

$ echo "AAAABX///9AAAAAAAAECAwAAAFAAAABk" | base64 -D | hexdump -C
00000000  00 00 00 05 7f ff ff d0  00 00 00 00 00 01 02 03  |................|
                      ^^^^^^^^^^^
00000010  00 00 00 50 00 00 00 64                           |...P...d|
00000018

Bytes marked with ^ represent the size of an array, which should be 1 since it contains only one address, but it has been changed to some very large number. As a result go-xdr is trying to allocate a large chunk of memory for the array that in reality is really small. Here's a little proof-of-concept:

package main

import (
  "github.com/stellar/go/xdr"
)

func main() {
  var message xdr.StellarMessage
  xdr.SafeUnmarshalBase64("AAAABX///9AAAAAAAAECAwAAAFAAAABk", &message)
}

A fix should check if the number of remaining bytes is less than or equal the specified size before allocating memory (you can check how it's works in xdrpp).

right now you have to create this Rate thing from the Offer struct before you can delete an offer

This modification stellar/stellar-core@e3e334d has not been processed in this stellar/go repository. I guess it has no technical impact, but the protocol should be the same in all services.

hash(x) and hash(tx)
stellar/stellar-core#846
stellar/stellar-core#965

Currently the code doesn't return an error, so it can fail (like it is, in my code) at one of the result.Mutate() and the entire operation will fail, but with a different error than the one that has actually ocurred first.

In my case, it is failing at result.Mutate(b), then what happens is that the TransactionBuilder pointer is not being copied to TransactionEnvelopeBuilder and thus txe.Base64() fails when it tries to check the underlying TransactionEnvelope for a NetworkPassphrase. The passphrase is not there only because the last step has failed totally.

Currently, running tests locally will fail without these services installed and running.

gets the outstanding orders of a particular account

Probably in all test files (I only picked a few to check). The arguments are switched.
the correct syntax is assert.Equal(t, expected, actual)
but I see a lot assert.Equal(t, actual, expected)

This is no big issue, but good to know when you are debugging.