Stellar Lumens (XLM) Forum with for newcomers and contributor's rewarded Check here

Jed McCalebSeptember 26, 2014
On Saturday September 20th, several of the Stellar validating nodes started failing. This eventually led to the network not reaching consensus on ledgers so all transactions came to a halt. Machines and the network came back about 11 hours later.
Incident Description:
From looking at the nodes and Zabbix historical stats, it is clear that most of the instances were running low on available RAM, as such the Linux OOM (“Out Of Memory”) killer was killing off pids on the machines in a bid to survive memory exhaustion.
Below are the main points outlining the outage which lasted approximately 16 hours from 20/09/2014 ~ 02:00 UTC until 20/09/2013 ~ 18:00 UTC

  • server_info : first ledger stopped being reported at 02:00 UTC

  • server_info : ledger age grew until 18:00 UTC

  • During the outage most nodes lost connection to the network (no ledgers, no peers)

  • Visible increase in disk reads on all volumes (db,rocksdb,rocksdb-cache).

  • Visible increase in outbound network traffic peaks.

  • All failed servers crashed due to memory exhaustion.
Judging from the graphs we can tell some servers died and others struggled during the outage although even the nodes that survived reported errors with peers/ledgers/ledger age.
During this time, there was not adequate communication with the community. We take full responsibility for the slow response, but want to let the community know why we were not able to respond immediately in this particular instance: At the time, the majority of us were at a company off-site working on designing a big refactor/redesign of stellard (ironically to fix the issues that caused this network outage). The servers started running out of RAM overnight. In the morning, the internet at our off-site location went out (along with two backup internet connections we had provisioned). We moved to a different location and we managed to stabilize the network. However our internet continued to have issues. During that time, it looks like the Stellar cluster continued to run out of RAM as well. The situation stabilized a few hours later.
Remedial Steps Immediately Taken:

  • Rebooted all the failed nodes and restarted stellard on some of the other nodes.

  • Downsized the stellard node_size to medium on all servers

  • Network came back online after we restarted a few more stellard
Single root cause is unknown but factors include:

  • Legacy code base having scalability issues. Stellar is the largest user base live on this code base and is testing the limits of this technology in real time. This outage has made us keenly aware of the scaling limitations of the current system, which we are presently working on.

  • Nodestore is leaking or using too much RAM.
Preventative Measures:

  • Completed: Rebuild validators with more RAM

  • Completed: Add additional team members to community channels so they can report updates from the Foundation in real time.

  • Completed: Reduce the monitoring alert output so we don’t miss legitimate issues.

  • Investigate alternative node store backends/config parameters.

  • Confirm whether application is leaking memory or not.

  • Create a “” page which can be easily updated with outage/progress reports.

  • Continued prioritized hiring for expansion of devops team members.

  • Continued rewrite of stellard to address the scalability issues.

  • Continued focus to expand the diversity and number of entities running validators (Decentralization is an important goal to ensure the robustness of the network).
We again apologize for the outage and have begun work on the preventative measures to avoid this from occurring again. If you would like to suggest any other preventative measures, we want to hear them. Please send them over to—thank you.

Read More Read More, Posted by: Stroopy
Joyce KimSeptember 18, 2014
We would like to welcome Graydon Hoare to our Core development team. Graydon is joining us from Mozilla and worked at Red Hat previously. He is the initial author of the Rust programming language, a systems programming language that targets high performance applications. Rust is well-known for both its technical clarity and its development process via open community contributions and feedback. You can read more about him here.

New Features
Early preview of trading functionality is now on our staging server.
Our temporary new Developers and Community pages are up. We decided to prioritize making good information available over visual design for now but rest assured, Romina and Winnie are building something easy to use and stunning for you all. Note, the purpose of the community page is not to be an exhaustive list of everything in the ecosystem, but to sample various interesting projects, companies and news.

Read More Read More, Posted by: Stroopy
Joyce KimSeptember 10, 2014

Our development team is growing. As of this week, Nicolas Barry will be working on our Core team. Nicolas is experienced in developing highly distributed and redundant applications and is joining us from Microsoft. We are happy to have him join the crew! You can read more about him here.
New Features Happenings
  • Justcoin became an anchor (supporting EUR and BTC).

  • Kraken and ANXPRO are now supporting STR.

  • The stellar giveaway crossed 1 million Facebook auths.

  • Someone made this site to help people navigate all the new services popping up in the Stellar system:

  • You can now top up prepaid mobile minutes in over 100 countries using stellars We tested it here:
  • Last week, we spoke at the SOCAP conference on a panel on “A Place for Digital Currencies in Financial Inclusion.”

Read More Read More, Posted by: Stroopy
Magnr is Bitcoin Trading and Saving Platform based on French.
What interesting here is Bitcoin Saving Account that gives you interest accrued on each EOM (End of Month)
This Saving Account somewhat almost similar to BitVC Saving Account by Huobi, the first to give interest through Bitcoin Saving.
What makes better, The Magnr site is based on English Languanges, while BitVC mostly based on Chinese Languages.

[Image: Magnr.png]

Read More Read More, Posted by: kurniawanism
Quote:More than $60m worth of bitcoin was stolen from one of the world's largest digital currency exchanges yesterday, and nearly 24 hours later, the event is still shrouded in mystery.
What is clear, though, is that the impact is far-reaching.
The Bitfinex theft represents the largest loss of bitcoins by an exchange since Japan's infamous Mt Gox lost 744,408 BTC in early 2014 (worth $350m), a breach that would ultimately cause it to cease operations.
At press time, the value of the 119,756 BTC stolen from Bitfinex stands at roughly $66m, or about 18% of what was lost by Mt Gox.
Given the size, the theft has sparked confusion and frustration among market traders and observers since it was announced.
Sources close to the exchange have largely avoided offering comment on whether the 119,756 BTC stolen represents the full extent of the hack, and Bitfinex itself has yet to publish any findings from its ongoing internal investigation.

Quote:The Bitfinex hack appears to be forcing the exchange to consider unconventional measures as part of a bid to relaunch after last week's $60m hack.
The Hong Kong-based bitcoin exchange announced last night that it is "leaning towards" a scenario that would see it socialize losses among bitcoin users and margin traders with BTC/USD positions. While not "set in stone", the idea that users could potentially share losses equally has nonetheless prompted speculation given the perceived impact the exchange's ultimate closurecould have on both the price of bitcoin, and its perception as a technology among the general public.
In the wake of the statement, market observers are attempting to assess the nature of the approach and whether it will be enough to resolve the issues at the exchange, one of the largest on the bitcoin network by volume prior to its shutdown.

After this event, the Bitcoin prices become unstable and the market mostly stagnant.
Do you think it will be fair to socialize the loses between users and margin traders? Not to mention the faulty not based on its' users and traders.

If Bitfinex defaulted, it might bring down Bitcoin Ecosystem, IMHO.

Read More Read More, Posted by: kurniawanism
I have problem creating account with
When I created or generated new account and get public + private key,
then try friend bot. But I do not get any free xlm to activate my account.

Then I bought stellar from exchange then tried to send xlm to generated account, it did not work. It said wrong address.

After that i creating stellar account from, and get new account, I can send xlm from exchange (which i bought xlm before) to my lobstr account. Any idea what was wrong creating account from

Read More Read More, Posted by: R1zk1
thank you, i've got stellar in my wallet on polo. btw, i can not found any info about how to claim stellar with exchange market, please help me. thank you

Read More Read More, Posted by: maydna
Does anyone have a comprehensive list of anchors and/or exchanges?
Reviews on any that you have used will be great as well

Read More Read More, Posted by: poliha2002
A stellar wallet address will not be activated until it has been sent 20 XLM.  For java-script developers, who just want to test the SDK, its possible to create a test wallet and have a "friend-bot" send you testing-XLM, so that your test-wallet can be activated. Not sure if this post should be in the developers section, although I should mention that I'm thinking of making a play-wallet-app that will auto-magically have test-funds so noobies like me can test out basic functions of the stellar test-network with their friends...will update this thread later once I have a demo ready...

Documentation :

Read More Read More, Posted by: mib00038
Stellar network upgrade is coming soon!

Joyce KimOctober 5, 2015
The upgrade to the Stellar network has been nine months in development and will be ready soon. The resulting network is safe, scalable, and accessible—critical features of a system that supports free and low-cost financial services for the world.
What you need to know
Users will need to upgrade. Here’s how it will work:
  • The upgrade will most likely come in November. The date will be finalized soon, with at least one week prior notice. Follow us on Twitter to stay updated.
  • An Upgrade button will appear in your account at When you upgrade, your stellars will be called lumens. If you have 20 stellars, you’ll have 20 lumens.
  • Once you’ve upgraded, you’ll be able to access your account and participate on the network using the account viewer. In order to stay focused on our core mission and encourage community ownership of the ecosystem, does not plan on significant development of the account viewer. Instead, we’ll continue to improve open-source developer tools so that participants in the ecosystem can build a variety of new services.
  • For developers and integrators: will be taking down its node on the old network. To learn more about what you need to do as a developer or integrator, please email us at

Questions about this process? Read the FAQs.
Safety first!
A note on safety: Do not sign in to your account from a link. To protect yourself, type the URL directly into your browser.

Please only access your Stellar account by entering the URL Do not click on account-related links that you find in social media posts or in emails claiming to be from or anyone else. Such links may be malicious.

To ensure that you’re logging into your own Stellar account and not into a fraudulent phishing scam account, bookmark in your browser. For more safety tips, read our article on avoiding phishing scams.
As an early Stellar user, you have helped shape this new upgrade. Thank you for being one of the first explorers, and for forging the future of Stellar.

Read More Read More, Posted by: san2ok
Reason, Why is Stellar switching its currency from stellars to lumens?
A lumen is just the new name for the native asset/currency  in the upgraded Stellar network. It's part of the Stellar network upgrade that has been nine months in development. The resulting network is safe, scalable, and accessible—critical features of a system that supports free and low-cost financial services for the world.

Read more about the technical aspects of the upgrade with Jed McCaleb's Multisig and Simple Contracts on Stellar.

so this explaining that  Stellar STR = XLM Lumens

Simple explanation they are "changing names, to differentiate Stellar Network and Lumens are its native Currency"

Read More Read More, Posted by: san2ok
Introducing Stellar
Joyce KimJuly 31, 2014
Stellar is a decentralized protocol for sending and receiving money in any pair of currencies. This means users can, for example, send a transaction from their Yen balance and have it arrive in Euros, Yen, or even bitcoin. We’re expecting to support the usual categories of transactions: payments to a merchant, remittances back home, or rent splits with a roommate.
You can hold a balance with a gateway, which is any network participant you trust to accept a deposit in exchange for credit on the network. Stellar also comes with a built-in digital currency, referred to as the stellar, which we’re giving away for free. The currency will have value (as determined by the market); however, its primary function is providing a conversion path between other currencies.
We hope that people will build applications on top of Stellar to help bridge the gap between digital and traditional currencies.
Get started
If you’re a developer and want to get started, here’s a quick introduction using our test network:

curl -X POST

We’re developing Stellar as part of a nonprofit organization, the Stellar Development Foundation. The code is open-source, and anyone is welcome to join the project. If you’re interested in following Stellar development or helping us build the network, just jump into our IRC room (#stellar-dev on Freenode), or browse the forums. You can start building applications on top of Stellar now; see Stellar Client (the code behind our hosted web client) or Stellar Viewer (the code behind the account viewer) for some working examples.
The following are some of the people involved (see our about page for a complete list): The currency
We provide an open-source hosted web client, where the keys are encrypted client-side to your password so we don’t have access to your funds. The supply of stellar willincrease at 1% per year.
The network has been initialized with a supply of 100 billion stellars. 5% will be used to fund operations of the nonprofit (its spending, including employee compensation, will be public), and the remaining 95% of the stellars will be distributed for free as quickly as we can manage. We want anyone to be able to get onto the network, and we’re correspondingly going to apportion the giveaway as follows (see our mandate for more details):
  • 50% of the total will be distributed to people who sign up for an account.

  • 25% will be distributed by other nonprofits focused on financial inclusion.

  • 20% will be given to current Bitcoin and Ripple holders—two systems that Stellar owes a lot to.
We’re starting the main giveaway now. Note that we’re still ensuring the stability of our own systems, so we may have to limit the rate of stellar distribution at first.
How it works
Stellar is built on the concept of gateways—entities that let people get into and out of the network. (For some related background, it may be worth reading Stripe’s recentcryptocurrency blog post.)
You need to trust the gateways you use, but you don’t need to trust the other participants in the network. This is similar to trusting your local bank to hold a deposit on your behalf. In Stellar, you explicitly decide how much you’d like to trust a gateway by setting policies such as “I trust this gateway to hold a deposit of up to 100 CAD on my behalf”.
Currency balances are represented as credits from the gateway. For example, a user could deposit 100 USD into an appropriate gateway via ACH, and the gateway would issue a “(100, USD, <gateway>)” credit to the user’s Stellar account. The credit issuance will only succeed if the user has already marked themselves as trusting the gateway for at least 100 USD.
[Image: gateway_diagram.png]
Credits can be traded between users without involving the gateway.
[Image: gateway_diagram_2.png]
Cashing out of the network requires invoking the promise represented by a gateway’s credits. You return those credits to the issuing gateway, and the gateway sends you the corresponding currency. Because the currency return is external to the network, you need to trust the gateway to follow through on their commitment (just as you trust your bank to return your deposit upon request).
Since it’s a distributed and open network, anyone is able to start their own gateway, and to take their pick of gateways to trust.
Distributed exchange
Stellar bakes a distributed exchange into the protocol. You can think of the exchange as a single large pool of offers of the form “I’ll trade (100, EUR, <gateway>) for (79, GBP, <othergateway>)”. Anyone on the network can issue a new offer, accept an outstanding one, or cancel an offer they created.
  • [Image: distributedex_1.png]

  • Anyone can submit orders to the exchange.
Outstanding orders to convert between a gateway’s local currency and stellar let anyone on the network send local currency credits to that gateway’s users. Behind the scenes, there might be a series of conversions along the way. For example, a user might submit a transaction which converts EUR credits to stellar and then converts those stellar to AUD credits. Ultimately, the user will have sent EUR, the recipient will have received AUD, and two exchange orders will have been fulfilled.
Under the hood, Stellar uses its own distributed ledger, which is maintained by a consensus algorithm rather than mining. Each node in the network communicates with a set of other nodes that it believes will not collude (such as nodes run by universities, governments, and companies). Importantly, it doesn’t need to trust the nodes themselves — it just needs to believe the nodes won’t work together to produce the same malicious result. Consensus is then reached by an iterative process, which results in each new ledger being decided upon every few seconds. Correspondingly, transactions confirm nearly instantly, and no mining is needed.
We’ll be releasing a paper soon documenting and exploring a provably-correct version of this algorithm.
The Stellar network is just getting started. Today, you can test it out by sending and receiving stellar (or you can use the API to play with running your own small-scale gateway, such as by issuing credits for minutes of your debugging help). We’re working with a few currency exchanges to help them become the first Stellar gateways; once they’re done, you’ll be able to transact in the currencies they provide. In the long term, there will be gateways to cover every payment method that people choose to support.
In the meanwhile, we’ll keep building, and we hope you’ll join us.

Read More Read More, Posted by: Forum IT
Stellar Consensus Protocol

The Stellar Consensus Protocol (SCP) provides a way to reach consensus without relying on a closed system to accurately record financial transactions. SCP has a set of provable safety properties that optimize for safety over liveness—in the event of partition or misbehaving nodes, it halts progress of the network until consensus can be reached. SCP simultaneously enjoys four key properties: decentralized control, low latency, flexible trust, and asymptotic security.
A few ways to explore SCP:
You can also watch Professor David Mazières’s talk on SCP:

A Federated Model for Internet-level Consensus

Read More Read More, Posted by: Rufus

When Jed McCaleb discovered Bitcoin, there didn't even exist an online marketplace to trade the cryptocurrency yet. The experienced founder who had earlier started file sharing site eDonkey, acted fast and started the first Bitcoin exchange MtGox which he later sold to now-infamous Mark Karpeles. Jed later founded the pioneering Ripple project before leaving to start Stellar.

We discussed his journey through the industry and the ambitious plans Stellar has to create an open financial system that will give access to financial services to a much broader spectrum of humanity.

Topics covered included:
  • Jed's early involvement in the industry and founding of MtGox and subsequently Ripple

  • Why Jed left Ripple and started Stellar

  • How Ripple and Stellar differ

  • The Stellar Consensus Protocol

  • Why the organization behind Stellar is a non-profit foundation

  • Stellar's focus on developing markets and Nigeria in particular

  • The role and distribution of Stellar's currency Lumen
Links mentioned in this episode:

Read More Read More, Posted by: Rufus
Implementing the Bitcoin Lightning Network on Stellar

I’ve been thinking about how to expand support for smart contracts onStellar, looking at use cases to learn what we need to make them viable. One of the most compelling things I’ve found is my friends Joseph Poon and Thaddeus Dryja’s smart contract-based proposal for bitcoin. It’s called Lightning Networks.  
Lightning allows you to set up a channel to send transactions securely between two parties, off blockchain. Neither party needs to trust the other—they only go to the blockchain to settle a dispute or to close the channel. Theoretically, any given channel could stay open for years and have millions of transactions flow across it without ever settling to the public ledger.
The two parties involved in the channel exchange pre-signed transactions without introducing them to the network. These transactions vary the fraction of the escrow amount sent to each end of the channel, a setup that is effectively equivalent to sending money between the two ends. Only the latest signed transaction should be valid between the two parties, but the network doesn’t know that—every transaction seems valid to the network. The trick is to set the channel up so that if either party introduces an old transaction, the malfeasor is penalized. Read the Lightning paper for a more thorough description.
A Lightning-like system is possible on Stellar today. Here’s one way you could set it up:

What’s involved
Setting up the channel will involve some of the more advanced features of the Stellar protocol: time bounds on transactions, accounts withmultiple signers, and batched operations.  
  • A: Account of one participant in the channel, (Alice, Adrian, Arkon, …)
  • B: Account of one participant in the channel, (Bob, Brody, Bevis, …)
  • Escrow: Account that holds the funds moved between A and B and the malfeasor insurance posted by each participant.
  • Helper: Account controlled by A and B that issues the assets needed by the channel. The helper account holds no funds.

  • SetupTx: Created and submitted to the network once to establish the channel.
  • CloseTxA & CloseTxB: These txs close the channel and return the correct balance to each participant. Creating a new closeTx is also how the balance between the two participants is changed while the channel is open. An A and B version of the closeTx make it clear who closed the channel.
  • RefundTx: This transaction finishes closing the channel and returns the insurance to the participants if there hasn’t been any bad acting. It can only be introduced a few days after a closeTx to give people time to submit a penaltyTx if there has been cheating.
  • PenaltyTxA & PenaltyTxB: For each pair of closeTx’s, there is a corresponding pair of penaltyTx’s. These transactions are only valid if one participant introduces an old closeTx. This action allows the other participant to introduce the penaltyTx and claim the entire insurance amount held in escrow.  

Information to track
Each participant must individually keep track of the following information outside of the Stellar ledger:
  • refundCounter: How many times the refundTx has been bumped.
  • txCounter: How many off-ledger transactions have occurred over this channel.
  • maxCloseTxTime: All closeTxs must be limited to execution before this time, allowing enough time for a penaltyTx to be introduced before the refundTx.
  • current balance between the two parties
  • latest refundTx
  • latest closeTx
  • latest penaltyTx

How it works
To make a Lightning-like system work, we use assets in a novel way. They act as a counter, relying on the fact that payment operations (and thus the entire transaction) will fail if the account doesn’t have the necessary funds.
The channel needs 3 assets: `AEND`, `BEND`, and `TIME`. What these assets are used for should become clear below.
To close a channel, either A or B must introduce a closeTx. These closeTx’s send a decreasing amount of either `AEND` or `BEND` to the escrow account. The penaltyTx that corresponds to a given closeTx requires escrow to hold more of the `AEND` or `BEND` then that closeTx sends to escrow. Thus the penaltyTx will only be valid if an old closeTx was introduced.
For example, if A closes the channel correctly:
  • A introduces the current closeTxA.
  • Escrow now holds X `AEND`, where X=(MAX_INT-txCounter).
  • But penaltyTxA needs to send X + 1 `AEND` so it fails and B cannot submit it.

But if A cheats:
  • A introduces an old closeTxA.
  • Escrow now holds Y `AEND`, where Y=(MAX_INT-old_lower_txCounter).
  • penaltyTxA is now valid since Y>X. In other words, escrow does hold enough `AEND` to send back to the helper account.

This logic should become clearer when you look at the actual transactions below.
The `TIME` asset works in a similar way for the refundTx’s.
Assume you have two parties, A and B. They want to create a lightning channel between themselves. A and B agree that the maximum either wants to pay the other is $100. They will each need to escrow $200: $50 for float to pay the other and $150 to post to ensure that neither can cheat.
A and B create, sign, and exchange the first closeTxB, closeTxA, and refundTx defined below. Then they create, sign, and submit the setupTx to the network.


Source account

  1. A creates escrow account
  2. B creates helper account
  3. A sends escrow $200 ($50 for float to pay B. $150 to provide malfeasor insurance.)
  4. B sends escrow $200 ($50 for float to pay A. $150 to provide malfeasor insurance.)
  5. Escrow trusts helper for `AEND` (asset we are using to know when A sends a closeTx out of order)
  6. Escrow trusts helper for `BEND(asset we are using to know when B sends a closeTx out of order)
  7. Escrow trusts helper for `TIME` (asset we are using to make sure old refundTxs aren’t valid)
  8. Escrow account sets A and B as the only signers
  9. Helper account sets A and B as the only signers


This transaction sets up the Escrow and Helper accounts and makes it so that any transaction from either requires A and B to sign.


Source account
Sequence number
current+1  (so isn’t valid until after some closeTx is submitted)
Time bounds
valid between: { now + 1 month, now + 2 months}

  1. Escrow sends {asset: `TIME`  amount: MAX_INT-refundCounter} to Helper
  2. Escrow sends $150 to A (*refunding the malfeasor insurance*)
  3. Escrow sends $150 to B (*refunding the malfeasor insurance*)


A makes, signs, and sends the refundTx to B. B signs it and returns it to A. Both A and B hold on to the latest refundTx but don’t submit it to the network until after a closeTx is submitted.
Whenever a new refundTx is created, maxCloseTxTime is set to (now + 1 month – 1 day).


Source account
Sequence number
Time bounds
valid between: { dawn of time, maxCloseTxTime }

  1. Escrow sends A  As_fraction_of_$100
  2. Escrow sends B  Bs_fraction_of_$100
  3. Helper sends {asset: `BEND` amount: MAX_INT-txCounter} to Escrow
  4. Helper sends {asset: `TIME`  amount: MAX_INT-refundCounter} to Escrow


A creates, signs, and sends the closeTxB to B.


Source account
Sequence number
Time bounds
valid between: { dawn of time, maxCloseTxTime }

  1. Escrow sends A  As_fraction_of_$100
  2. Escrow sends B  Bs_fraction_of_$100
  3. Helper sends {asset: `AEND` amount: MAX_INT-txCounter} to Escrow
  4. Helper sends {asset: `TIME`  amount: MAX_INT-refundCounter} to Escrow


B creates, signs, and sends the closeTxA to A.


Source account
Sequence number
current + 1 (so isn’t valid until after some closeTx is submitted)

  1. Escrow sends {asset: `AEND` amount: (MAX_INT-txCounter)+1 } to Helper
  2. Escrow sends $300 to B


A creates, signs, and sends the penaltyTxA to B.


Source account
Sequence number
current + 1 (so isn’t valid until after some closeTx is submitted)

  1. Escrow sends {asset: `BEND` amount: (MAX_INT-txCounter)+1 } to Helper
  2. Escrow sends $300 to A


B creates, signs, and sends the penaltyTxB to A.
Anytime A wants to send a transaction, they create and sign a new closeTxB with the updated balance between the two parties. B replies with the corresponding closeTxA and the penaltyTxB. A then sends penaltyTxA and the off-chain transaction is considered complete.
As time inevitably marches forward and gets close to maxCloseTxTime, the parties can increment the refundCounter and generate a new RefundTx. Future closeTx’s will be created with the updated refundCounter and maxCloseTxTime.
Happy path
A and B merrily exchange closeTx’s until they no longer want to maintain the channel. At that point, one of them introduces the latest closeTx and then both sign a transaction dividing up the insurance.
A cheats and introduces an old closeTxA
Let’s say that at some point there was a closeTx that sent $70 to A and $30 to B, but then A sent $45 to B over the channel. As a result, the current closeTx sends $25 to A and $75 to B.
A might be tempted to introduce the old closeTx. However, if A does that, B can submit the latest PenaltyTxA, which will succeed: Because of the old closeTxA, the escrow account now holds too much `AEND`. A can’t submit the refundTx before B has a chance to submit the penaltyTx. The current refundTx isn’t valid until sometime in the future. Since closeTxA is time-bound, it must have sent the current amount of `TIME` asset to escrow. Thus an old refundTx will fail because escrow doesn’t have enough `TIME` asset to send to helper.
Channel closes but B is a jerk
If the channel was closed correctly but B decides not to sign a transaction dividing up the insurance, A must wait for the pre-signed refund transaction to be valid and then submit it to the network.
Note: The channel in this example is for USD, but it could work with any currency or asset. There’s a bit of extra work I left off to ensure that A or B don’t remove their trust of the channel asset, which would prevent the close and refund transactions from working. But it’s possible to set up in a safe way, which I’ll leave as an exercise for the reader. (If the channel is for lumens you don’t have this issue.)
Going Further
Setting up a payment channel between two parties is just the first step in creating a full-fledged lightning network. The network becomes even more powerful when you can chain parties together and chain channels between totally different ledgers or blockchains. But more on how to do that later…

Jed McCaleb
Stellar Cofounder

Read More Read More, Posted by: Rufus


Help us Spread the News and Stellar Lumens XLM (Formerly known as STR)
Banner Rules Posting