rivine / home

Your starting point in to Rivine

Rivine

Blockchain technology for creating custom chains.

Whitepaper

You can reach out to us for any development-related questions on our public Telegram group.

Repository has been moved

This repository is no longer active. Rivine has been moved to a new organization and its development is continued in its new home at https://github.com/threefoldtech/rivine.

Usage

This project comes with 2 binaries, rivined and rivinec. rivined is a background service, or "daemon," that runs the Rivine protocol, and rivinec is a client that is used to interact with rivined. rivined exposes an HTTP API on 'localhost:23110' which can be used to interact with the daemon. Documentation on the API can be found in doc/API.md.

rivined and rivinec are run via command prompt. On Windows, you can just double- click rivined.exe if you don't need to specify any command-line arguments. Otherwise, navigate to the rivine folder and click File->Open command prompt. Then, start the rivined service by entering rivined and pressing Enter. The command prompt may appear to freeze; this means rivined is waiting for requests. Windows users may see a warning from the Windows Firewall; be sure to check both boxes ("Private networks" and "Public networks") and click "Allow access." You can now run rivinec in a separate command prompt to interact with rivined.

Building From Source

To build from source, Go 1.9 or higher must be installed on the system (older versions of GO might work, but we don't support it). Then simply use go get:

go get -u github.com/rivine/rivine/cmd/...

This will download the Rivine repo to your $GOPATH/src folder, and install the rivined and rivinec binaries in your $GOPATH/bin folder.

To stay up-to-date, run the previous go get command again. Alternatively, you can use the Dockerfile provided in this repo. Run docker build -t rivine . to build and docker run --name rivine rivine to start the daemon. Running the client can be done with docker run -it rivine rivinec. Add client commands just like you would calling rivinec normally (like docker run -it rivine rivinec wallet transactions).

Supporting a Rivine Wallet in a Light Client

Should you wish to support Rivine, or more likely a Rivine-based wallet in a(n) existing/new light client, it is recommended that you read /doc/transactions/light_wallet.md as a starting point.

This document references to (most of the) other documentation you'll need in order to develop your own light wallet for a Rivine-Protocol-based blockchain.

Troubleshooting

• I can't connect to more than 8 peers.

  Once Rivine has connected to 8 peers, it will stop trying to form new connections, but it will still accept incoming connection requests (up to 128 total peers). However, if you are behind a firewall, you will not be able to accept incoming connections. You must configure your firewall to allow Rivine connections by forwarding your ports. By default, Rivine communicates on port 23112. The specific instructions for forwarding a port vary by router. For more information, consult this guide.

  Rivine currently has support for UPnP. While not all routers support UPnP, a majority of users should have their ports automatically forwarded by UPnP.

• I loaded a seed, but my coins don't appear yet.

  After loading your seed, you will need to stop and restart your daemon. If after that the coins still haven't appeared (and you are sure they should be there), you can try rivinec wallet addresses to force load some more addresses.

  Note that when you recover a wallet from an existing seed, using wallet recover, effectively creating a new wallet using an existing set, your addresses will already be loaded when unlocking it.

• My daemon exits imediately upon startup, giving the error: error opening consensus database: invalid argument:

  Make sure that the file system you are using for your daemon's persistent directory supports features such as mmap and flock. Shared folders for example, as is common in virtual environments or containers, might not support mmap and therefore will fail to function. The scenario in this example can easily be resolved by making sure the persistent directory isn't located within a shared folder.

• My node can be out of sync with the network for hours, if not days.

  Do you have multiple nodes —which includes the out-of-sync node— running on a single external IP using the same port within the same blockchain network? If the answer is yes, you should ensure that all those nodes are using unique ports for the RPC address.

  If not already, you will run into problems sooner or later when running multiple nodes using the same external IP address and RPC address port within the same blockchain network.

home's Issues

Prepare Human energy token

threefoldfoundation/hechain

Bring the core rexplorer code to the rivine organization

Currently the redis dump code resides in the threefold organization:https://github.com/threefoldfoundation/rexplorer
I propose to bring this to rivine and have threefold use it the same way it implements the rest of rivine.
This will improve the reuse for new chains

milestones not properly set over the account

please use milestones which correspond with your home page

e.g.

there should have been a 1.0.7
goal is to have over full account only these milestones 1.0.7 - 1.0.8 - 1.1 ... and nothing more

rivine explorer dumps all info -> redis server

these specs are prob double & need to go elsewhere, but need something to organize our thoughts.

address = 
tokens_amount = 
locked_up_till = epoch
multisign = [[address,state],...] # state is bool

address means wallet address

Farmer registration

Y es, we can abuse the arbitrary data for it but we can also make a special kind of transaction
I t would be easier to distinguish and if more business rules need to be added later, it will become messy if the current transactions are used for this

Glen, [16 Oct 2018 at 07:02:03]:
I think he will need the farmer ID, the different capacity units (CPU, Memory, HDD, SSD) and perhaps also GPU and Bandwidth range?

Further KDS requires that 10% goes to the Foundation, and top of that, if the farmer is part of a cooperative, a certain percentage goes to that cooperative as well. Meaning the first 10% we can just hardcode as a rule of that transaction, not difficult. But the cooperative one would depend if it is part of a cooperative, so somehow, when a farmer registers capacity, it might also need to mention this cooperative or get it involved somehow, so their rules can be applied as well.

Rob Van Mieghem, [16 Oct 2018 at 07:02:54]:
yep, I think we all agree a special transaction is a lot better

Improve the jumpscale blockchain code and documentation

• By default reuse an input address for the change in the Rivine wallet send_money method threefoldtecharchive/jumpscale9_lib#98
• Add rivine Create and Open wallet convenience methods threefoldtecharchive/jumpscale9_lib#90
• Make the seed optional in the rivine wallet creation threefoldtecharchive/jumpscale9_lib#89
• Use the base token value instead of hastings for the txfee in the j.clients.blockchain.rivine.wallet creation threefoldtecharchive/jumpscale9_lib#85
• Move j.clients.blockchain.Electrum to j. clients.blockchain.btc.Electrum threefoldtecharchive/jumpscale9_lib#82
• Use the atomic swap transactionid instead of the outputid in j.clients.blockchain.rivine.atomicswap threefoldtecharchive/jumpscale9_lib#81
• Add the Ability to use multiple explorers/daemons to j.clients.blockchain.rivine threefoldtecharchive/jumpscale9_lib#80
• Add a tft client to j.clients.blockchain threefoldtecharchive/jumpscale9_lib#79
• Better documentation for j.clients.blockchain.rivine threefoldtecharchive/jumpscale9_lib#78
• Add an atomic swap walkthrough example for the rivine blockchain client threefoldtecharchive/jumpscale9_lib#76
• Add btc electrum atomic swap support threefoldtecharchive/jumpscale9_lib#27
• Improve rivine multisig wallet threefoldtecharchive/jumpscale9_lib#125
• Refactor tfchain code to use rivine base threefoldtecharchive/jumpscale9_lib#128
• Ability to get a seed from a tfchain wallet threefoldtecharchive/jumpscale9_lib#151
• Different generated address handling for the tfchain client threefoldtecharchive/jumpscale9_lib#88
• Support uncornfirmed transactions in the balance check threefoldtecharchive/jumpscale9_lib#178

Ibiza presentation

Practical hands-on session: Blockchain (Rob & Lee?)

• How to install rivine & Electrum (BTC)
  • In ZOS (use zos tool, need to be pre-defined solution)
  • Configure for test nets
• Use command line clients
  • Show wallet
  • Do some transactions
• Use js9 scripts and do
  • Atomic swap between BTC/TFT
  • Do transaction put description inside.
• Use the rexplorer
  • Show how to get info out of the chain

Support 3bot

Will be added to the ThreefoldChain

spec see https://github.com/rivine/home/blob/master/specs/3bot_registration.md

Add the coincreation and minterredefinition to jumpscale

Reorganize the atomic swap repos

I propose to have a “atomicswap” repo with the decred repo as a submodule or vendored instead of the fork we have now, this way we can put the buildscript next to it and the electrum code in there as well

we have only 1 atomicswap tech repo this way

Ethereum erc-20 tft tokens and bridge

ERC-20 is a technical standard used for smart contracts on the Ethereum blockchain for implementing tokens.

General idea

A lot of the bigger exchanges support erc20 tokens but it would require some effort to support tftokens directly. By creating an erc20 token to represent tft, these exchanges can support an and transfer tft amongst each other without any effort.
We propse to be able to send tft to an ethereum address, he bridge would create the tfterc20's and add them to the target ethereum address. Maybe multisign is required to secure this.
The reverse depends if we can encode a tft adress in an eth adress, if not, a receiving adress needs to be published on the tft chain first. A user can withdraw from an exchange to an eth adress generated by a tft wallet and a blockcreator node would include the coin creation transaction to a block. Every full node can run a validator to only accept valid eth to tft transactions.
This would allow user to easily convert tft to tft erc20 and back, making the process to transfer tft to an exchange that supports tfterc20 and back almost seamless.

Unconfirmed transactions in explorer and light clients

When querying an explorer for an adress, the unconfirmed transactions should be returned too.
This allows a better user experience for people using the web explorer and makes it easier for light clients, now they have to seperately query the transaction pool which can also cause timing issues.