We need a new transaction type that allows for the creation of oracles.
The first oracle should be either a single address, or a multisig of several addresses. The participants in the oracle are the people who know the private keys for the addresses that make up the oracle.
If a decision is given to the oracle, then the oracle can profitably answer the decision.

Eventually a mechanism will be added to the oracle to encourage the participants to be honest.

In order to have a solid and single understanding we need to come up with a glossary of terms used in the FlyingFox protocol. This will make us all read the same page when we talk and discuss about the protocol and how to further extend it.

we need to add more checks onto the tx so that the mempool never adds a tx that would cause us to crash.

poor people are able to buy blocks they cannot afford. their balance goes negative.
the data structure looks bad: [{"BCmhaRq42NNQe6ZpRHIvDxHBThEE3LDBN68KUWXmCTKUZvMI8Ol1g9yvDVTvMsZbqHQZ5j8E7sKVCgZMJR7lQWc=", [cash: 1.999999752e15, bond: 99787469469734.95]}, {:cash, [cash: 1.99999969e15, bond: 99787469469734.95]}, {:bond, [bond: 99787469469704.95, cash: 1.999999752e15]}]

encrypted messaging would be even better if it onioned the routing. that is where you have layers of encryption, and the message passes through multiple nodes and gets another layer removed each time. We should do this to hide the location of the validators.

It would be nice if messages could sit in queues on the nodes, that way you can send a message to someone who is offline, and when they come back online they can pick the message up from the mailbox.

This is the terminal output

larry@larrybox:~/FlyingFox$ sh start.sh
==> jiffy (compile)
==> cowlib (compile)
==> ranch (compile)
==> cowboy (compile)
==> FlyingFox (compile)
GO TO THIS WEBSITE -------> http://localhost:3011/main.html
Erlang/OTP 18 [erts-7.1] [source] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false]

Eshell V7.1  (abort with ^G)
1> {"init terminating in do_boot",{undef,[{port,start_server,[],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,669}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}

Crash dump is being written to: erl_crash.dump...done
init terminating in do_boot ()

each tx with a fee needs to have a hash of a recent block in it. Otherwise the same tx could be used to build a fork.

A decision is a function that returns either true or false. The function can be written in any language, even english. Oracles look at decisions in the consensus state, and they decide whether the outcome is true or false.

Decisions in flying fox need to be able to exist inside of channels. When the channel state is published to the blockchain, then the decision is added to the consensus state.

The text of a decision never gets published onto the blockchain. Only the hash of the text is published.

Decisions have expiration dates. The oracle cannot judge on the outcome until after the expiration.

If a decision exists in the channel state of one of your channels, then you and your partner can bet on the outcome of the decision.

currently we protect private api calls by putting them behind the loopback interface.
Another alternative would be to require signatures for all these commands.

Requiring signatures would be nice, because it would be easy to manage nodes from afar.

the idea was introduced here: https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/

Weak subjectivity is necessary for security reasons. It stops long range attacks.

as currently implemented, when you send encrypted messages the pub key of the sender is leaked.
Here is a simple fix:

(bad idea omitted)

If you have an open channel with someone, and the channel's expiration period is shorter than a day, then you need to have a computer turned on almost all the time. Your computer watches your partner, and if your partner tries to end the channel on the wrong channel state, then your computer alerts the blockchain to the correct channel state to stop the theft.

If your computer wan't on, then your partner could have stolen from you.

This same program should also look for lightning opportunities. If 2 people on either side of you want to pass money, then you should take a small fee and let them use your channel to accomplish their payment.

The same program should also search for arbitrage opportunities in betting. If 2 people you are connected to want to bet on opposite sides of an oracle, you can take both bets at favorable prices and earn money regardless of the oracle's decision.

Scenario: 2 users are engaging in a smart contract through 3-step channel through a server. The server goes off-line. The users don't want to publish the contract, they want to continue using it, as is, onto a different server.

I currently think that server switching is impossible. The contract has to get broadcast and re-created through a different server.

This feature depends on weak subjectivity.

The idea of fast sync is that we don't check the validity of any transactions. Instead we assume the blocks are valid, and read them in as fast as possible.

Fast syncing is only for loading old block. Very recently created blocks cannot be fast synced.

The idea is to have a standard interface in order to be able to talk to different clients and frontends that are going to use our node. That being said, we would want to be able to talk also to browsers. This means we need to have some sort of HTTP interface in order to serve both JSON (AJAX) and/or WebSockets if we want to stream real-time data from our nodes to the different frontends.