Thunder Network

Mats Jerratsch - matsjj@gmail.com

Your thunder was heard in the whirlwind, your lightning lit up the world; the earth trembled and quaked. -Psalm 77:18

A productive prototype implementation of the Lightning Network on a client-server model with simplifications to allow for a similar experience with features readily available today.

This prototype is made up on two back-end libraries and a client front-end. I used bitcoinJ to have a proper framework for all of the bitcoin logic, and implemented my modifications of the LN, from here on called Thunder Network, as it is thought of a predecessor of LN.

My current estimate for OP_CLTV and OP_CSV activation is around Q3 2016. I will shift my work towards implementing the changes proposed by Rusty Russel. [1] Changing the design of the channel is trivial, but there are many unresolved problems like routing that are open for discussion on the mailing list.

This will allow for full P2P networks with hubs/nodes of varying sizes and is a no-trust solution. Due to the short timespan until the needed features are available, pushing ThunderNetwork into the masses is not reasonable.

Big nodes and a client-server alike structure can always evolve out of a P2P network due to natural economics - if necessary. The same does not hold true the other way round.

For now I will stick with the basic server/client architecture, such that users can also choose to just be ‘most basic customers’, it’s like full node vs. SPV. The servers on their own will form a P2P mesh, where users can chose their nodes. Client and server mostly differ in their connectivity, as servers will have a very high uptime, where clients should not bother about that.

GitHub Repository

https://github.com/matsjj/thundernetwork

Downloads (v0.0.2)

Due to some problems with JRE I bundled everything together into a portable .rar for Windows users.

Portable .rar (Windows) ThunderWallet.rar

Executable .jar (Other OSs) ThunderWallet.jar (requires JRE 1.8+)

This software is in alpha status and a work in progress. The main goal of this project is to provide libraries that can be used in other, more widely used wallets. The GUI provided is just a prototype to show the functionality.

It is a portable version, you can run multiple instances as long as they are based in different directories.

Addresses are one-time-only, due to the no-trust. Read below for more information.

Changelog Wallet

0.0.2

Added realtime updates (using websockets)

Added basic interface for thunder:... requests (needs further OS implementation for activation)

Various bugfixes

Roadmap

[ 50% ] Server Functionality

[ 40% ] Client Functionality

[ 10% ] Testing

[ 10% ] Security Hardening

Working

Server-Client Communications

Open Channel

Make Payment

Redeem Payment

Update Channel

Close Channel

Key Management using BIP32 and hardened HD-Keys

Server

Monitoring Blockchain for Transactions

Claiming Outputs for revoked Transactions

Broadcasting Refunds and Settlements for correct Transactions

Necessary for MainNet

Server-Client Communications

Restore Channel on Client

Server

Increased Backup Services

Removal of Hot Wallet

Extensive Monitoring

Client

Monitoring Blockchain for Transactions

Claiming Outputs for revoked Transactions

Broadcasting Refunds and Settlements for correct Transactions

ClientGUI

Various Features (esp. Data Consistency)

Planned Features (depending on interest)

Server-Client Communication

Payment Request Interface for seamless Integration with various other Programs

Automatic Payment towards specified Users for Micropayments

Changelog Document

11.08.2015 Announcement

13.08.2015 Added No-Trust Solution using only OP_CLTV

Added Payments in older Channel Versions

Donations appreciated:

13KBW65G6WZxSJZYrbQQRLC6LWE6hJ8mof

Motivations

The lightning network allows new features on top of the current bitcoin network. Among those are instant transactions and a better scalability, while reducing the cost for individual transactions. As the network runs into fundamentally based capacity problems, one solution may be to offload uncritical transactions (that is, everyday transactions, especially transactions <10$) to a centralized service, while preserving many of the very important properties of using bitcoin.

The initial proposal of the lightning network required some new features, that required at least a soft fork (most importantly SIGHASH_NOINPUT in P2SH), pushing any real implementation many months or even years into the future. A recent suggestions changed the channel design such that we only need two new OP_CODES, with one in deployment already. While these changes are less controversial, it is still not possible to foresee how long it will take until these changes are fully implemented.

I therefore changed the channel design of the initial paper such that it can be implemented with the tools currently available in bitcoin. While such a channel does no longer work in a completely trustless manner, it is a good trade-off to start implementing LN. Most importantly, it allows deployment of software using something similar to the future LN implementations for now. Changing all the infrastructure from using the blockchain to LN is the most difficult task and it will take a long time to establish a reliable network.

With a centralised server-client model, it will be easy to swap out outdated software, as new features in bitcoin will allow for better channeldesign in TN. Any new ruleset can be enforced by the server and implementing the thunder network in a library fashion will make it easy for software developer to adapt to new changes.

As this is a low-trust and not a no-trust solution, a decentralized network with many different payment hubs is currently not possible. One trade-off would be to have one higher-level payment hub, that act as a central hub, with other hubs as clients. This would, however, not solve any of the issues with just having one payment hub in the first place. Furthermore, all the benefits and drawbacks of having a really large network with over thousand different payment hubs have yet to be determined.

The Channel Design

The design of the channel is based on the initial proposal of the Lightning Network, that needed SIGHASH_NOINPUT to work properly.

The need for SIGHASH_NOINPUT is for two reasons:

The design of transaction ids in bitcoin does allow for mutability. As transactions can be changed with a new signature, the id does change and subsequent transactions can no longer be broadcasted, as the referenced id does not exist.
Some of the needed transactions (especially the payment settlement tx) can not be built completely during channel creation, due to the very nature of the design. As a preimage is needed to claim an output that is yet unknown, we cannot have transactions building upon this transactions (as we don’t know the txid until we know the preimage)

Thunder Network tries to mitigate these two problems, trying to preserve as much of the integrity of the LN design.

Updated channel, with v0 revoked. The updated channel includes a payment from a client (A) to the server (B).

Updated channel, with v0 revoked. The updated channel includes a payment from the server (B) to a client(C).

All design decisions were made to have unresolved trust issues due to the lack of SIGHASH_NOINPUT shifted towards the server. As others may have more funds and incentives to shut down such a service, attacks must not result in a loss of server funds. Also, the server has an additional incentive to stay honest, due to the possible loss of reputation that the client does not have to fear, as he is can act anonymously. A breach of contract on the server side will become public across social networks instantly, while a breach of contract from the client will likely have no consequences.

Furthermore, the channel were designed such that the serverside channel is still very close to the initial design, allowing little room for malicious activities. Only the clientside channel has been changed, such that the server cannot enforce it.

Channel Creation

As funds of both parties get locked up in a multisig manner, it is possible to hold funds of the other party hostage at the expense of your own funds. Therefore refund transactions are created prior of the broadcast of the channel transaction. That party that is broadcasting this very transaction can however resign and therefore change the transaction id, invalidating the refund transactions.

In thunder network, the server will create an unsigned transaction with inputs from the server, and outputs to the channel and to his change addresses and communicates it with the client. The client can afterwards add his inputs and change outputs, sign his inputs and send it back to the server. The server can sign his inputs and does have the complete transaction. He should not broadcast it though, because the two parties still need to interchange the refund transactions.

Channel creation therefore always happens on the serverside. The server _could_ resign, but has further incentives to stay honest.

Revocable Change

Both parties have their change encumbered in an revocable output in their respective channels. By exchanging the own private key to a multisig output, we allow the counterparty to steal our funds, as the transaction that we hold is timelocked. The timelock of this ‘revoke transaction’ is always set to the end of the channel. It serves as an descentive to broadcast old channel transactions. Also, resigning and thus invalidating the revoke transaction will only cost the malicious party money, as the change of the other party is not encumbered.

Payment Outputs

From here on we have to distinguish between the side the channeltransaction resides. As the client cannot be assumed to act honestly, the outputs of his channel has been changed in favor of the server.

Additionally we have to distinguish between payments to the server (Alice to Bob) or payments to the client (Bob to Carol), as the latter bear an increased risk of malicious activities.

Payments from the Client to the Server (Alice to Bob)

serverside:

…

clientside:

The settlement output is not paying to a multisig between client and server, but only to the preimage and sig server. Without this change, the client could mutate the txid, invalidating the payment, as the settlement transaction on the server is not invalid. The drawback of this change is that the server _could_ claim payments even after the refund period, as it is not timelocked, while the refund transaction is timelocked until the end of the channel. However, the server can only claim the payment, if the receiver disclosed the preimage with him. With knowledge of the preimage, the client Alice has provable paid to Carol, as was his very intention when he made this payment in the first place. The refunds to the client need to be timelocked until the channel ends, as he could claim the refunds from an revoked channel after the refund period.

Payments from the Server to the Client (Bob to Carol)

serverside:

…

clientside:

Here we have the biggest change in the design. In case the client does not provide the preimage in time, we want the funds to return back to the server, the classical refund. This is important, as the server cannot claim the associated payment from the initial sender of the payment Alice after a specified refund time. Therefore it is crucial that the receiver cannot claim these funds after the refund time.

On the contrary we want the receiver to be able to claim the funds, if he does provide the secret preimage. At best, there should be nothing the server can do, to interfere with this.

On top of that, we also have the malleability problem, as the client can resign, rendering all possible multi-sig outputs invalid.

These three problems cannot be sufficiently solved with the current set of features in bitcoin, so we need a design with a good trade-off. As the server is assumes to act honestly at all times, the output is freely accessible by the server. This means, the server can claim the payment at all times. As a compromise, the settlement transaction for the client is not timelocked, such that the client can try to outrace the server by broadcasting both transactions with not delay. He can even claim payments from revoked channels. If this will be misused a lot maliciously, we have to adapt and timelock the settlement transaction up to the end of the channel, making it completely revocable, as all other outputs.

The worst the server can do, is to collect the secret preimage from the client, but not update the channel transaction accordingly. He can then collect the payment from the sender and wait till the payment times out on the receiving end, thus keeping the payment. However, it is assumed, that this breach of contract will be made public very soon, and the possible loss of reputation is incentive enough to stay honest. Furthermore, larger payments can always be cut into smaller payments, making this attack less attractive.

Payments in older Channel Versions

There is a problem, as settlement transactions are not time-encumbered (we want that whoever deserves the output of a payment to be able to claim it instantly, with no one possibly interfering). This means if one party has a channel transaction with a payments towards it, he can claim this payment under any circumstances. However, if this party does broadcast a revoked channel to claim such an output, the counterparty can still steal all settled funds and all funds towards his channel.

It is therefore important to keep track of the amounts the other party is receiving. We have to know, which is the highest amount the other party ever had as receiving payments in his channel, and we must make sure that we decline any attempts of him spending money, such that his balance would drop below this amount.

This will be more clear using this example:

We start with a channel, with Alice and Bob, and both fund the mutual channel with 10 BTC.

So at t=0 we are at

Alice - 10 BTC

Bob - 10 BTC

Now imagine that for some reason, Alice received payments, such that she has 5 BTC as uncleared payments in her channel.

t=t1

Alice - 10 BTC ( +5 BTC uncleared )

Bob - 5 BTC

She reveals the secrets and Alice and Bob settle those payments, leading to

t=t2

Alice - 15 BTC

Bob - 5 BTC

Now if Alice were to be free to spend all her money, if we don’t enforce the above rules, she could spend all her money (leading to legitimate payment contracts in other channels that we are obliged to).

t=t3

Alice - 0 BTC

Bob - 20 BTC

But, as reasoned above, payments towards Alice can always be claimed by Alice, such that she can claim the 5 BTC from the t=t1 channel transaction and Bob losing those 5 BTC. The t=t1 transaction does spend 5 BTC directly towards Bob, and he can also claim the 10 BTC settled balance from Alice, but his net balance compared to the t=t3 is -5 BTC.

To defend against this kind of attack, it is important to keep track of the maximum the other party has as receiving uncleared payments in his channel. In this case, the maximum Alice has as uncleared receiving payments is at t=t1, 5 BTC. This means, we have to make sure her balance does not drop below 5 BTC anymore. As agreeing on a channel with a payment is a mutual action, Bob can just refuse to accept a new channel transaction, where the balance of Alice would drop below 5 BTC.

This rule also serves as an incentive to clear out receiving payments as soon as possible. The party who has sent a payment (Carol in this example) can only remove settle the payment after the receiving party has cleared the payment, and we don’t want the channel to clog.

Actual Timeframes in TN

I made some guesses about the timeframes that are acceptable. These are likely to change in the future, as actual users can give feedback.

Total Duration of Payment:

7 days ( 604800 seconds )

This is the total duration for one payment. If the client updates his channel after this time, the payment will get refunded and added to his balance again.

Time to Add Receiving Payment

3 days ( 259200 seconds )

If the receiver does not update his channel to include a payment within this time after the sender issued the payment, it will get refunded.

Time to Reveal Preimage

3 days ( 259200 seconds )

If the receiver does not reveal the preimage to a payment after this time, the server will

broadcast the complete channel.

These timeframes have the following implications:

If you expect a payment, you should update your channel / check for payments at least every third day, as you may miss payments otherwise
If you added a receiving payment to your channel, you should reveal the secret as soon as possible, as you may miss the 3 days timeframe, and the server may broadcast the channel, resulting in a lot of fees.
The last 7 days of a channel, it will get locked internally, disabling all payments to and from the channel. By this we achieve, that at the end of the channel, all payments will be either refunded or complete. Increasing any of the above timeframes will also increase this ‘dead time’.

Addresses

Solution 1: Include all necessary information of the payment into the address

It is favorable to have addresses that are at least similar to the current system of addresses. For a payment in the TN, we need at least the following information:

an identifier of the receiver. This can be a given usertag, a pubkeyhash, or a random id. It is needed for the server, to know which client can produce the preimage needed to claim the payment
the hashed preimage. This needs to be supplied by the supposed receiver, and submitted by the sender. A preimage may never be used twice, as the server can steal funds of any additional payments with the same preimage, as soon as the receiver revealed it once.
the TN payment hub of the receiver.

(1) and (2) can be added together, with a prefix and checksum into an address very similar to bitcoin addresses. (3) can be implemented into a suffix, similar to email addresses. This also serves as an easy way to reach out to the other payment hub without an additional central address register. Furthermore, (3) can be omitted for payments within one payment hub.

XAAAAAAAAHHHHHHHHHHHHHHHHHHHCCCC@DDDDDDD.TLD

X - 1 byte to declare which kind of identifier we use (see (1) above)

A - 8 byte to clearly specify a receiver

H - 20 byte, the hashed preimage needed for the payment

C - 4 byte to serve as a checksum against typing errors

D.TLD - domain, under which the TN server of the receiver can be reached

Example: 1DGoLbrgsXrNSnV3Scc9a2bnAmqsBZYFB1vUkRFp3ogz@thunder.network

This will lead to a total address length of 33 bytes + domain. We will base58 encode the 33 bytes to have an address that is easy to copy-paste and possible to transcribe manually.

It is therefore still possible (and advisable) to have payment requests similar to those used in bitcoin today encoded in small QR codes.

To further move to having a similar use-flow as we have in Blockchain transactions, it would be great to have reusable addresses.

To make a payment to someone over thunder, we use a hash, such that the payment can only be settled, if the receiver reveals the preimage of the hash. This ensures that the payment hub is not able to steal the funds, which is is fundamentally important to have a no-trust solution. This also means, if we send a payment to an address that has been used and settled already, the payment hub knows the preimage already, and he can claim the payment for himself, without asking the receiver for the preimage.

However, if we find a function f, pub and priv, such that

f( pub(seed), t, r) = RIPEMD160( SHA256( f( priv(seed), t, r) ) )

with

t - timestamp

r - random number (1-10000)

we can replace the hash in the address with pub(seed), and the client can interpret the address, such that he will use f(pub(seed), t, r) to calculate a hash to encumber the payment. The timestamp and the random number will serve as a nonce, and a random number between 1 and 10000 will sufficiently reduce the probability of a collision, while preserving the ability to brute force the preimage for the receiver.

The problem with this is of course finding those functions. Especially since a hash function is designed with the explicit goal to make it infeasibly difficult to find a correlation between input and output.

Using pub/priv key pairs instead of hash/preimage pairs would be possible, but it would not solve this issue. With BIP32 we have to decide between

(1) using normal derivation. However, exposing one private key together with the seed will expose the whole chain. ( https://bitcointalk.org/index.php?topic=679487.0 )

(2) using hardened key. This will remove the problem in (1), but it is impossible to derive any children with only the public seed, such that it is no use for our purposes.

In the end, there is always the possibility to use some intermediary. Some service that is producing hashes randomly and only reveals the secret to the receiver with some user system. However, the payment hub could engage with that service and defraud all users of their open payments. Maybe it is possible to have the preimages encumbered in such a way that a password is needed to decrypt them, but the service can still refuse to reveal the secrets (hostage) or vanish completely (for whatever reasons).

Solution 2: Include Contact Information Necessary to Obtain Payment Instructions

Another possibility requires the receiver to be online whenever he wants others to send him money. We can include information, such that the sender can (directly) connect to the receiver. They can then exchange all instructions necessary for the payment, like the hash, and maybe a route. Additionally, the receiver can also sign and commit a contract, attesting the sender that he made the payment if he can provide the preimage to the hash.

There are some difficulties to overcome, especially since the receiver might

not be online when others wish to make a payment.
not want to be reached out to directly. (requires further layers for anonymity)
is not accepting incoming connections, due to NAT or a firewall.

Ideally, we would include different instructions on the preference of the receiver, with fallback methods in case they don’t work out. Using solution 1 and just include the hash directly in the address can work for many use-cases, where we don’t even want to receive multiple payments. (Like for many eCommerce systems).

The downside of this flexibility is that what we refer to as addresses currently, will turn out to be large blobs of data. Transcribing them manually will be very inconvenient and payments will mostly be made over URI requests lightning:... or QR codes. Both techniques will not help in cases where you want to make a payment from a device with no camera (as a PC) to a mobile device like a smart phone. In these cases, shortening services might resolve this issue.

Fees

Server Fees

A general discussion about the possibilities of fees was outlined in the initial paper of LN. We will have a more specific discussion about the fees in a proper implementation of a TL payment hub here.

There are two different kind of fees that we have to consider

fees, due to the maintenance of a server that is able to handle all the requests properly,
fees, due to the funds we need locked up, such that other parties can exchange value.

(1) is very straightforward. We have real-world costs running a service that need to be addressed. As costs has to be paid in fiat, this fee has to be thought of as fiat aswell. It should be a flat fee, as the monthly costs are only dependent on the amount of payments, and not on the funds exchanged. For the current exchange rate of around $300, 20 satoshis per payment can be enough to cover these costs.

(2) is a much more abstract kind of fee. It is needed, especially in the beginning of a new TN payment hub, to build up enough funds. It has yet to be determined which fee is sufficient here, and it is mainly dependent on the movement of funds, how often money is changing hands. We can calculate the total funds necessary by

FUNDS = MONTHLY EXCHANGED BITCOINS / TURNOVER OF EACH BITCOIN

It makes sense, to have a percentage fee here, as higher payments need more funds. Also it is possible to omit these fees, as soon as enough funds has been collected. It is then enough, to only have (1) fees, enabling very cheap transactions.

For now, we will start with one percent of the payment as (2). It will make TN payments cost efficient over blockchain for payments up to $5, while having instant payments. These costs will be deducted from the amount of the receiver, such that refunds will not cost any money. In case someone attempts a DDOS attack by issuing lots of payments, we may change this policy, to charge (1) off of the sender.

As soon as the TN payment hub does have enough funds ready, (2) will probably get lowered to 0.1 percent or lower to fund further development. A fee market can arise from there on as well, with different payment hubs. In this case, a cap will be probable as well, to stay competetive even for larger payments.

This fee structure does allow for micropayments much more efficient than any other payment processor currently. The minimum payment amount of 1000 satoshis is currently worth $0.003 and can be collected paying 3 percent in fees.

Blockchain Fees

As the TN payment hub does not collect much fees and also bears the risk of losing his funds to malicious actors, paying the fees necessary to open and close a channel is not sustainable. Therefore all transaction fees are paid by the clients.

Risks

Some of the risks outlined in the initial LN paper can be mitigated using different techniques.

Hot Wallets

As usual webservers are not considered safe, we generally do not want the webserver to hold any private keys. More precisely, we do not want a webserver to hold information which allows for unauthorized payments. For a future implementation of TN, it will be possible to mark a channel as ‘receiving-only’. This action cannot be undone, and the flag will remain up until the end of the channel. When the flag is set, the TN payment hub will reject any payment request from this channel. While it is still possible for a hacker to create a valid payment request, sign it and send it to the payment hub, without the payment hub acknowledging and processing the payment, he is not able to receive any of the money in the channel. Furthermore, the webserver is still able to accept payments, and the final output address for the channel can be set to a safe offline wallet as well.

Data Loss

Part of the TN protocol is a way to restore the last agreed on channel. The server will send the last version of the channel transaction that was signed by the client and also issue a new version for the client. While there is a trust problem, the client can do this for zero cost once a week or even more often to test the honesty of the server. As the server does not know if the request is a test or not, he does have incentive to act honestly. Furthermore, both parties can decrease the master key depth by one, revoking all old channels.

Malicious Server

In case the server is compromised, for whatever reasons, these are the risks associated with the users:

The server can resign the opening transaction, locking in funds of both parties. He can then try to demand some of the funds of the client, the classic hostage situations. However, unless all clients give in to these demands, the server will likely still lose money overall, since for each uncooperative client, he does lose all the funds associated in that channel.
The server can block all requests to/from a client, rendering the channel useless. Both parties will not have access to their funds, until the agreed date, at which the refund transactions will become spendable.
The server can resign a channel transactions, rendering all depending multisignature-outputs invalid. This includes the unspent funds of the server. As payments in the serverside channel transactions are also encumbered in multisig-outputs, these will be locked up, resulting in a hostage situation again.
The server can wait for a broadcasted channel transaction from a client, resign, and broadcast it again, trying to reach more nodes. This attack can be difficult to perform, as the client can choose to which nodes he will broadcast his transaction. Furthermore, channel transactions will very rarely be broadcasted at all. This will result in a complete lock up of all funds belonging to the client, while the server can still access his funds. This attack can also be done other way round, such that it is important for the server to be very well connected.
The server can claim payments to a client, using the unencumbered output to his key, racing against the client.

(1) to (4) can mostly be considered as vandalism. The server is not directly benefitting, but rather hopes the client gives in in a hostage situation. Only (5) directly earns the server money. Also note, that all these attacks can not only be identified as such, but the client can cryptographically proof the breach of contract. If the server does broadcast a revoked channel transaction, the client can proof he does own both private keys of the encumbered outputs. As all messages from and to the server are signed, (2) can be proved accordingly. (1), (3) and (4) can be proved, by comparing the transaction in the blockchain with the (server signed) refund / settlement transactions. Finally, if you can find a transaction that is trying to claim outputs of a payment before the agreed refund time, you have proven that the server tried to engage in (5).

It serves as an additional descentive, as any malicious action from the server can be instantly proven, and other clients can close their channels accordingly.

Outlook

With OP_CLTV merged already, we can further solve some of the problems inherent in TN. Furthermore, also OP_CSV will probably get merged, such that both OP codes might be useable within the next 24 months. In line with the original proposal, it is also possible to include SIGHASH_NOINPUT. Either way, with one of these two, it is possible to establish complete trustless intermediate hubs for instant payments, using either the original design or the design proposed by Rusty Russel.

OP_CLTV

With OP_CLTV, it is possible to change the opening transactions, such that it will contain two outputs. Both outputs will pay to their respective owners after the agreed refund time. This means, that there will be no specific refund transactions, removing all risks associated with the channel opening. All channel transactions will need to include both inputs, with both parties signing both inputs.

Furthermore, the output for a payment towards a client in a clientside channel can have the refund time included, such that the server can no longer race against the client in claiming these outputs.

No-Trust Solution using only OP_CLTV

It is furthermore possible, to create a channel design using just OP_CLTV as a new feature that is completely trustless, although it does still suffer from some of the problems in the current thunder-design.

With OP_CLTV it is possible to replace the payout-to-multisig-and-give-timelocked-partly-signed-transaction with a simple OP-code, specifying for how long the output should not be spent. With this it is able to completely mitigate all the malleability problems we have in our current solution. Let’s take a look into some of the changes made and their implications.

Opening Transaction

There are no longer refund transactions that needs to get interchanged. It is possible to directly make the refund to both parties part of the opening transaction. This completely removes any risk problems and allows for large amount of funds within the channel. As soon as the refund time has come, both parties can get their respective funds back with just their sole private key. As we cannot accomplish the exact distribution with just one output and CLTV, we use two outputs that only differ in the refund private key. By doing so, any channel transaction has to include both these outputs (and of course both has to be signed accordingly), leading to larger transactions.

Channel Transaction

Settled Funds

We use the same mechanism as in the opening transaction here, and added a multi-sig output to ensure that these funds are revocable. If both parties agree on a new version of the channel, they release their temporary signatures A2 and B2. If a party broadcasts a channel that was marked as revoked, the other party can steal those funds. Furthermore, malleability is no longer an issue, as refunds are only timelocked using CLTV, and in case of a revoke, the other party has both private keys. In any case, we are no longer depending on having a specific transaction presigned by the other party.

Sending HTLC

Making a payment now consists of 3 outputs. We combine the mechanism for refunds and for revocable transactions (see above) with the ability of the receiver to claim the payments in case he knows the secret R. We lowered the refund time to the general timeframe of a payment, such that it is enforceable by the sender. Again, as we don’t depend on presigned transactions, malleability is no longer an issue.

Receiving HTLC

The outputs of a receiving HTLC are very similar to those of a sending one, but with the private keys set accordingly. Also the timeframe is down to 6 days, such that we have plenty of time to determine if a payment will get refunded or not.

Now there are a couple of problems with this design, mainly that HTLCs are not strictly revocable. If one party broadcasts a revoked transactions with HTLCs inside, the other party can just try to race against the propagation of the claiming transactions, which will often be fruitless. This goes for receiving payments, where the party can claim the funds with the secret R and also for sending payments, where he can use the refund option (for revoked channels which are older than the refund timeout). We could set the timeout of the refund up to the total channel, but this would have many further implications.

Having sent a payment, you can no longer enforce a refund. As payments may either refund or not, it is difficult to pass the payment on to another party. This is especially true if the sending channel ends before the receiving channel. In ThunderNetwork we like to have all payments in a defined status - either refunded or settled - at the end of the channel. Therefore we enforce a locking period at the end of each channel, where making a payment (and having others making payments toward that channel) is not possible anymore.

Additionally, this new channel design means that a channel will get closed and broadcasted completely, as soon as the refund condition for any payment in your channel is met. To counter this as a receiver of a payment, you have to reveal the secret or settle a new channel without the payment (manual refund) in time with the other party. As a sender, you have to check back the payment before the refund, to work out with the other party if the payment should refund or settle.

Those timeframes are just for illustration, it might be preferable to play along with those numbers a bit. For example, the one day difference between the sender and the receiver means that in extreme cases the sender only has one day for updating his channel. Furthermore, there isn’t really a reason the receiver has 6 days time to reveal his secret, where 6 hours would be plenty of time as well. Finally, we can also extend the period for a payment, resulting in a longer lock-up time frame at the end of the channel.

With channels being strictly no-trust, we can move towards larger amounts of funds inside the channels, mitigating the problem with non-revocable HTLCs and the workaround. It just becomes one additional rule we have to apply among all the others that are apparent already.

Implementing these changes in the current Thunder implementations is trivial. It comes down to deleting a lot of methods currently necessary and switching to the new scripts. This goes for most channel design changes, as the design of Rusty for example.

EDIT: With the publication of the OP_CSV BIP I recognized that there are discussions about combining CLTV and CSV into one softfork that I wasn’t aware of. With this in mind, it is of course no longer practical to implement a solution just using half the potential, when you can just as well go the full way.

Implementation Details

Project Structure

Currently there are 3 projects inside the main folder.

The server
The client, that will build into a back-end-library
A Prototype of a GUI-Wallet, building on top of (2)

Communication

All requests to the server are directed towards the API URL thunder.network/api. Furthermore, JSON is used for requests, with fields such that

int TYPE Type of the request
String PUBKEY Base64 representation of the parties pubkey
String DATA Object, including the data for the request
int TIMESTAMP Current timestamp, to prevent replay attacks
String SIGNATURE Base64 representation of the signature for the request

Depending on the type of request, different fields have to be present in the DATA-object. In case of any failure, TYPE will be -1 and the DATA field will contain detailed information about the error.

Currently, there are 5 major request types.

Establishing the Channel

The channel will be established in 3 phases.

Making a Payment

Requesting a payment consists of 5 phases. While only 4 phases a technically necessary, the fifth request will ensure data consistency.

Updating the Channel

Updating the channel consists of 4 phases. With the update, both parties reveal secrets of payments currently included in the channel, such that those will be removed, with the balance added properly.

Closing the Channel

Requesting the closure of a channel only consists of one phase.

Restoring the Channel for the Client

[TBD]

Routing

The basic problem with routing payments is to have - at best - a solution that is preventing analysis in any form, but also scales well to billions of transactions a day. It would be best if we can issue a payment to some kind of ‘address’, but have no further information about the receiver. Additionally, the receiver should further not have any information about the issuer of the payment. These requirements should not depend on good-will, but should be a requirement of the system. That is, it should fundamentally be impossible to derive these information for anyone.

Currently we differentiate between 'Users' and 'Hubs', such that a user will always have a connection open to a hub to receive payments.

However, if we treat both the same - address wise - any prior nodes in the chain of a payment can't determine, whether a node has accepted the payment for himself or for another node further down the chain. Using such a technique, it is basically possible to tell in which direction how much money is flowing, but it is impossible to determine the start- and endpoint of each payment. A node can has no knowledge, whether the other party is acting on behalf of some other node or just for himself.

We need some way to ensure the payment will reach the receiving node though, without disclosing any information about him. The routing model of the TOR project might come in handy here, as they solve exactly this problem. The trade-off for this is a massively increased latency, as payments requests will (necessarily) be larger and efficient routing will most likely be more difficult to do.