The Bitcoin Forum

Hi everybody,


I think this is a good time and place to announce the existence of Flex.

Flex lets you move and trade cryptocurrencies by breaking the private keys into many parts and scattering them among a network of untrusted nodes. Protocols for passing secrets verifiably and recovering information held by dead or malicious nodes are used to prevent theft or loss of secrets.

You can send bitcoins or other cryptocurrencies in seconds, and the transfer doesn't leave a trace in any blockchain.

It's also a decentralized exchange. You can trade cryptocurrencies without trusting any individual, and with a trusted third party, you can also trade fiat.

White paper: https://peer-node.github.io/flex/files/flex.pdf

Protocol specification: https://peer-node.github.io/flex/files/protocol.pdf

Github: https://github.com/peer-node/flex

Here's a screencast demonstrating the ability of Flex to zip bitcoins from person to person in seconds:
https://vimeo.com/145687724#t=512

It should start near the end of the screencast so you don't have to watch the installation and configuration process. I'll give a more verbose explanation of what's going on there in the next few days, maybe with an edited version of the video.

I think this opens up new possibilities for scaling bitcoin, and could have some commercial applications. For example, it could be used at checkouts since it takes only 8 seconds to irreversibly transfer coins.

The Flex software is available under the terms of the AGPL software license. This ensures that the software will remain free (gratis and libre) and at the same time makes it possible in the future to sell commercial licences to support development. This software is a working prototype, but to scale properly Flex will need to grow into a mature peer-to-peer network like bitcoin. The dual licensing scheme ensures that those who step forward to help Flex succeed will face the prospect of remuneration and emoluments. Contact me if you see the potential of the project and want to help move it forward.

Right now we're seeing the problems of scaling a global cryptocurrency start to manifest themselves. If Flex becomes big and strong, we could help to ease some of those pressures.

Thanks to Roger for providing the forum and, I guess... ask me anything.


Peer.

In this post, I'll explain how to configure Flex to use electrum.

In later posts I'll explain how to create, transfer and withdraw from deposit addresses as well as trade currencies.

First, you'll need to be running Ubuntu 14.04. You can probably get it to work on other linux distros as well, but the list of dependencies for Ubuntu 14.04 are in the "packages" file, so it's easy to install.

Once you've cloned the github repository, you can go to the flex/python directory and do: That will compile and try to install the executable and the supporting python scripts. If you're not root, you won't have permission to install it system-wide, so before you try to install it, you can do: This will give you a non-root python installation and doing python setup.py install will install it there.

Once you've installed it, you can configure it: This will create the configuration file ~/.flex/flex.conf. It'll assign Flex to port 8733 by default, and use 8732 for rpc.

You'll need to have a copy of the latest version of electrum (2.5.2), and due to some bugs in the electrum server code, you need to choose ecdsa.net
manually as the electrum server. You'll also need to have an unencrypted wallet (i.e. no password) and, due to this issue:

https://github.com/spesmilo/electrum/issues/1494

you'll need to create a wallet by pasting this code: into the ~/.electrum/wallets/default_wallet file.

You'll also need to have at least one address in your electrum wallet. This is so that Flex can ask electrum for an address and study it to discover, effectively, what the first letter is (bitcoin addresses start with a 1; litecoin addresses start with an L and so on).

The way to do that is: Before you paste the code above into the default_wallet file, export a private key and then, after you've pasted into the file, re-import that private key.

When you start the electrum gui to set the server to ecdsa.net, it should list some of your bitcoin addresses. Suppose one of them is 1abcdefghijklmnopqrstuvwxyz. Close the gui and then, from the command line, do: This starts electrum running so that you can interact with it via the command line. Then do: It will respond with a private key that looks something like Kfvdf372364g7486f47c24763h32982743h872hfer9fgr8q.

Then stop electrum: Then paste the code shown above into the default_wallet file, and do: Then if you do: it should show you the address whose private key you exported (1abcdefghijklmnopqrstuvwxyz in this example).

Now you need to make electrum available via rpc so that Flex can talk to it. You can do that by doing: The "daemonize" command is included with Flex and it turns a command line program like electrum into an rpc service listening on a specific port. The flexcontrol configure command tells Flex that there's a cryptocurrency with the currency code BTC available on port 8008.

Then you're good to go. You can start Flex and see if it's connected to electrum: If you get a balance of -1, it means that Flex failed to talk to electrum. Try watching the demonstration screencast referenced in the OP and copying the sequence of actions exactly, if you keep having problems.

If you get a balance of 0, all is good. You can then either start mining to create a new chain: Or, if there's another node that's already mining, you can connect to it and synchronize with it: Shortly after doing either of these (mining or downloading), you should get details other than all zeroes when you do: Among the information that you'll see in response to the getinfo command is the number of relays. These are the entities which hold parts of secrets. If there are enough relays (about 9 or 10), you can request deposit addresses and trade coins.

In this post, I'll explain how to send bitcoin and other cryptocurrencies in seconds using Flex.

I'll presume that you have two users who are synchronized to the same chain and who both have electrum connected to Flex.

This means that they both get the same details when they do: The one thing that will be different between two users will be their balance. They should see the same batch number, number of relays and so on, and these numbers shouldn't be all zero.

Both users should also get a number other than -1 as a result when doing: If all that is true, then wait until the number of relays reported by flex-cli getinfo is about 9 or 10.

Then one user can do: Nothing will happen after you hit enter. This is because the request has to be encoded into the chain before any relays are assigned to handle it. We need to do it that way so that nobody can predict or control which relays get assigned.

You'll have to wait for 2 more batches to be mined before you get your deposit address. After that, you can do: It should show you a bitcoin address, with a balance of zero. Send a small number of bitcoins to it, but not so small that your transaction is regarded as dust. 0.002 might be a reasonable number of bitcoins to send.

Then you'll have to wait for the bitcoin transaction to get a confirmation. Once it's confirmed, you can do: again, and you'll see that the deposit address has a balance of 0.002 or whatever number of bitcoins you sent.

Now you've got bitcoins ready to send at high speed to the other user. Let's call the other user user2, and let's call the user with the 0.002 bitcoins at the deposit address user1.

User2 will need to have a Flex address to which the deposit can be sent. Doing: will give you a new address. Then get user1 to do: where the expressions in angle brackets, <>, should be replaced with the corresponding addresses.

A few seconds after that, user2 will be able to see the deposit address and balance when doing: The deposit address will have disappeared from user1's list. Now user2 owns the deposit, and you've just sent bitcoins from one user to another in a few seconds.

User2 can withdraw the deposit to his or her electrum wallet: Then you can do: to see the address in your wallet, and will show you the balance. You can stop the daemon and start the gui: if you want to "see" the balance in your wallet. It's ready to spend, seconds after you received it. There's no need to wait for any confirmation because the coins are still at the deposit address they were originally sent to.

For me, electrum getbalance doesn't show the updated balance after a key has been imported. You have to open the gui to get it to update.

All of these steps are shown in the screencast at:
https://vimeo.com/145072408#t=1620

so if you have problems, you can try to reproduce what's shown in the video.

If you still have problems, you can post in this thread and I'll do my best to solve them.

Here's an edited version of the video. There are some captions which might make it easier to understand what's going on.

https://vimeo.com/145687724#t=512

It skips to the point where the bitcoin deposit is confirmed. Then you can see the bitcoins travel from user to user and then finally into an electrum wallet.

The earlier parts show how to install flex starting with cloning the github repository. Then it shows how to configure it and connect it to electrum. Then it requests a deposit address and bitcoins get sent to it.

I've fixed a bug in the latest version at github.

Previously, if you tried to transfer or withdraw a deposit before the deposit address had been confirmed (i.e. the associated secrets were disclosed to a second set of relays and they didn't complain), it would fail silently. Now it will fail with an error that says something like, "Can't transfer until address secrets have been disclosed".

In this post, I'll describe how to trade cryptocurrencies using Flex.

To make life easy for testers, Flex includes a test currency which is activated by default. If you've got Flex running using "flexcontrol start" as described above, the you can do:
Among the results you'll see the currency code CBF there. That's the code for cyberfarthings. There's an included command line-tool called cbf which behaves like a cryptocurrency. You can do:
You get 10,000 CBF to start with, and you can delete the file /tmp/cyberfarthings_wallet.pkl or reboot your computer to reset your balance back to 10,000.

Users on the same computer can send cyberfarthings to each other, but it's not actually a peer-to-peer network, so you can't trade with users on another machine (although you can achieve this using a trick described in the README.md file on github). It's also not a secure payment method or store of value. There's a single wallet shared by everybody and anybody can edit it.

So there's no security and no peer-to-peer network, but there is still the same relationship between addresses and private keys. If you know a private key, you can spend cyberfarthings at the corresponding address.

This means that all of the secret-splitting tricks employed in Flex can be used with cyberfarthings, and there's no need to risk bitcoins or other coins with unstable software. The reason that I used bitcoins in the demonstration video above and explained how to connect electrum to Flex is that if I had done it with cyberfarthings, nobody would believe that it really lets you send bitcoins quickly. It would be more plausible that I was demonstrating something that only works for fake coins made up by me like cyberfarthings.

So here I'll describe how to trade cyberfarthings, CBF, for Flex credits, FLX, and I'll suppose that, by watching the video and perhaps playing with the software yourself, you've managed to overcome your disbelief that Flex works with bitcoins.

Cyberfarthings are much more convenient since you don't have to wait for any confirmations. Transactions are instant.

To accomplish a trade, you'll need two users on the same machine, running Flex instances which are synchronized with each other as described in earlier posts in this thread. You'll also need to wait until there are 8 or 9 relays before you can trade. Since the users are on the same machine, only one of them will be able to use the default ports. You'll need to edit (e.g.) user2's ~/.flex/flex.conf file to change the ports (e.g. add 1000 to each).

Check that cyberfarthings are connected and working by doing:
If you've got 10,000 cyberfarthings, then you're doing well. Now unless you did "flex-cli setgenerate true" after user2 synchronized his or her chain with user1's, only user1 will have any FLX. So user1 can buy some cyberfarthings from user2. Let's say user2 places an order:
This says that user2 wants to sell 5,000 cyberfarthings for a price of 0.0000001 FLX each. user1 can see the order by doing:
As you can see, the order is on the "asks" or "sell" side of the CBF order book.

If user1 doesn't see anything in the book, but user2 does, it means that the chains aren't properly synchronized. Try getting user2 to do "addnode" and "startdownloading".

Once user1 can see the order, and there are enough relays, user1 can
accept it: If you check the balances just after this, you'll find that user1's FLX balance (which you can see by doing "flex-cli getbalance") has dropped by more than 0.0005. This is because the smallest credit in user1's wallet is larger than this and user1 will get the change when the transaction is encoded into the chain. This will take two blocks, or about two minutes.

I know two minutes is a long time to wait for a trade. Sorry about that. If you're trading a real cryptocurrency like bitcoin, you'll need to wait for at least a confirmation or two of that currency.

Anyway, after you've travelled a few minutes into the future, you can check user1's CBF balance:
and see that the cyberfarthings have arrived. You can also check user2's FLX balance:
So the trade is complete.

Let me know if you encounter bugs or difficulties trading with Flex, and I'll do what I can.

In this post, I'll describe a feature of Flex which allows you to send and receive bitcoins with some degree of privacy - private deposit addresses.

Using private deposit addresses is almost as simple for the user as using normal deposit addresses.

Suppose that Alice wants to send 0.01 bitcoins to Bob, and both Alice and Bob are happily connected to the Flex network with electrum connected as described above.

Alice then does:
Then she waits for a few minutes (so that the request can be encoded into the chain) and does:
As you can see, Alice now has a deposit address with no bitcoins in it. It says that "private" is "true", which means that nobody apart from Alice (and later, whoever she transfers it to) knows the address.

Alice's software achieved this by choosing a random number and using that as an offset for the deposit address that she received from the network. The address shown above was not the address that the network generated (which we could call the public address). Instead, it shows (to Alice) the result of adding the secret offset to the public address.

Alice can then send bitcoins to this address using her favorite bitcoin wallet.

It's important to realize that when Alice does this, the address shown above becomes visible on the bitcoin network, and everybody who knows that Alice controls the originating address knows that Alice sent 0.01 to someone. In fact, you can look at blockchain.info and see the transaction for yourself.

What they don't know is that she sent it to a private deposit address that she generated using the Flex network. The way that private addresses on the Flex network differ from regular deposit addresses is that nobody who is recording traffic on the Flex network will be able to see which bitcoin transaction funded Alice's private deposit address.

If Alice had used "requestdepositaddress" instead of "requestprivateaddress", then anybody recording all Flex network traffic would see which deposit address was generated in response to Alice's request, and could then watch for bitcoin payments to that address. Upon seeing a payment, they would know that 0.01 BTC had been sent to a Flex deposit address, and if they knew that Alice controlled the address that sent the funds, they would know that Alice is using Flex to transmit bitcoins.

With the private deposit address, it just looks like Alice sent some bitcoins somewhere.

Now Alice can send the coins untraceably to Bob. For this, she needs to know a public key for one of Bob's Flex addresses.

Bob can generate one by doing:
That long string of hex is a public key. Bob gives it to Alice in the same way that he would normally give her a bitcoin address. Then Alice can do:

Eight seconds later, Bob can list his BTC deposit addresses, and he'll have the private address that Alice created:
and Alice won't have it any more:
Bob can then send the deposit on to a third recipient within 8 seconds or withdraw the bitcoins to his bitcoin wallet and spend them immediately.

From the point of view of somebody who is watching only the bitcoin blockchain, no transaction has taken place at all. Alice sent the 0.01 BTC to the address 13KSehmmk43DDt8VrJJv2GvqYv7mPDWM4a and they stayed there.

From the point of view of somebody watching the Flex network only, a deposit address was generated, and no funds were sent to the public address. Then the address was transferred. If Bob has pasted his public key on a public website, then somebody who sees that public key and monitors the Flex network will see that Bob has received something. They won't know who sent him something and they won't know how much was sent.

For somebody monitoring both the bitcoin blockchain and the Flex network, they will see that Alice sent 0.01 BTC somewhere and they will see that Bob received something, but there will be no way for them to make the connection between Alice and Bob, even if they know both the public key that Bob uses to receive private deposits on the Flex network and that the address which sent the 0.01 BTC was Alice's.

It's also worth noting that Flex doesn't keep a record of deposit transfers in a blockchain, so anybody who wants to know that Bob received something will need to be listening at the very time it occurs.

So somebody monitoring all traffic on both networks will fail to make the connection between Alice and Bob. This is to be contrasted with the situation in bitcoin, in which the fact that Alice's key paid bitcoins to Bob's key is public knowledge for all time.

I think it's worth pointing out that this software is available and works right now, and lets you send bitcoins with this degree of privacy in seconds.

What doesn't exist yet is an always-on Flex network which everybody can connect to and be on the same network. You can try it out on your own computer, or make a network with friends and send coins between yourselves. Soon, though, I'll post IP addresses of seed nodes for the Flex network and then everybody can connect, mine, trade and send coins in seconds to one another.

It's still experimental software and comes with no warranty, though. You can consider it a testnet, even though it's capable of transmitting real coins. It may restart or crash due a bug at any time, possibly while your coins are at a deposit address, so don't put any coins into it that you aren't prepared to lose. You can use the native currency, FLX, in deposit addresses to experiment with peer-to-peer transfers, or CBF if you're doing your testing all on one machine. This will allow you to avoid the risk of losing bitcoins in a computer mishap.

After it's been through enough testing, it will be launched as a live network. Then fast, private bitcoin transactions will be available to all.

After you start Flex running by doing:
you can point your browser to This will show you the calendar, which if you haven't started mining or synchronized with another node, will be empty. As you mine, it will start to fill up.

The calendar is a bit like a blockchain, but only one block gets into it each day on average. A trick (concatenating branches of Merkle trees) is used so that this collection of once-a-day blocks are all that a new user needs to download in order to validate transaction inputs. This means that you'll never have to download a 50 Gb blockchain to synchronize with the Flex Network.

You can click on the hashes in the calendar and see what's inside the corresponding objects. There are different types of messages in there: join messages, deposit address requests and others. All of these are described in the white paper and the protocol document, and of course, in the source code.

If you've synchronized with somebody else's chain, you might not have the entire history of all transactions. This explorer will, of course, only let you navigate through the data that you've downloaded. By clicking through it you'll see that you can see payments to hashes of public keys, and if you click on one of those key hashes, you can see all the payments that address has received that you know about.

Unless you've downloaded the entire history, or have been connected since the beginning, any given public key could have received a payment that you never knew about. When the keyholder wants to spend it, the keyholder includes in the transaction a long Merkle branch, connecting the transaction input all the way to an entry in your calendar, which proves to you that the input was really included in a batch that was encoded during the construction of the calendar.

So instead of making everybody download the entire history of transactions, each person stores enough information to prove that his or her own credits are valid.

Hi everybody,


I think this is a good time and place to announce the existence of Flex.

Flex lets you move and trade cryptocurrencies by breaking the private keys into many parts and scattering them among a network of untrusted nodes. Protocols for passing secrets verifiably and recovering information held by dead or malicious nodes are used to prevent theft or loss of secrets.

You can send bitcoins or other cryptocurrencies in seconds, and the transfer doesn't leave a trace in any blockchain.

It's also a decentralized exchange. You can trade cryptocurrencies without trusting any individual, and with a trusted third party, you can also trade fiat.

White paper: https://peer-node.github.io/flex/files/flex.pdf

Protocol specification: https://peer-node.github.io/flex/files/protocol.pdf

Github: https://github.com/peer-node/flex

Here's a screencast demonstrating the ability of Flex to zip bitcoins from person to person in seconds:
https://vimeo.com/145687724#t=512

It should start near the end of the screencast so you don't have to watch the installation and configuration process. I'll give a more verbose explanation of what's going on there in the next few days, maybe with an edited version of the video.

I think this opens up new possibilities for scaling bitcoin, and could have some commercial applications. For example, it could be used at checkouts since it takes only 8 seconds to irreversibly transfer coins.

The Flex software is available under the terms of the AGPL software license. This ensures that the software will remain free (gratis and libre) and at the same time makes it possible in the future to sell commercial licences to support development. This software is a working prototype, but to scale properly Flex will need to grow into a mature peer-to-peer network like bitcoin. The dual licensing scheme ensures that those who step forward to help Flex succeed will face the prospect of remuneration and emoluments. Contact me if you see the potential of the project and want to help move it forward.

Right now we're seeing the problems of scaling a global cryptocurrency start to manifest themselves. If Flex becomes big and strong, we could help to ease some of those pressures.

Thanks to Roger for providing the forum and, I guess... ask me anything.


Peer.

This sounds very exciting! This is like Shamir's Shared Secret but much more advanced. I'd like some smarter people to look at your Whitepaper and code, as it starts to go over my head! But in general, your thesis seems promising.

Thanks for your kind words!

The code will be professionally audited and I hope that in addition many keen eyes and sharp minds will review the concepts and the implementation for vulnerabilities.

Ultimately I think that the best way to secure the system is to have as many people understand it as possible, so once there's a test network up and running, I'll write a series of expository posts to hopefully make the concepts accessible to a wider audience.