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




Joyce KimDecember 5, 2014
This week, the Stellar network experienced a ledger fork that is related to a failure of the underlying Ripple/Stellar consensus system. We are completing our review of the impact, but early reports indicate that the impact was not major. We are reaching out to all the known gateways and exchanges to see what we can do to assist.
Given how novel consensus systems are and our belief that we should be transparent about the technology, which includes its strengths and weaknesses, we wanted to provide some context for the ledger fork and how it happened in Stellar.

Issue 1: Sacrificing safety over liveness and fault tolerance—potential for double spends
The Fischer Lynch Paterson impossibility result (FLP) states that a deterministic asynchronous consensus system can have at most two of the following three properties: safety (results are valid and identical at all nodes), guaranteed termination or liveness (nodes that don’t fail always produce a result), and fault tolerance (the system can survive the failure of one node at any point). This is a proven result. Any distributed consensus system on the Internet must sacrifice one of these features.
The existing Ripple/Stellar consensus algorithm is implemented in a way that favors fault tolerance and termination over safety. This means it prioritizes ledger closes and availability over everyone actually agreeing on what the ledger is—thus opening up several potential risk scenarios. For instance, there may be situations in which nodes diverge on different ledgers and a person can’t be certain which ledger the network will ultimately decide to take. If the network switches to another ledger chain, then transactions from the discarded chain will be invalidated—this opens the network up to potential double-spend problems.

Issue 2: Provable correctness
Prof. David Mazières, head of Stanford’s Secure Computing Group, reviewed the Ripple/Stellar consensus system and reached the conclusion that the existing algorithm was unlikely to be safe under all circumstances. Based these findings, we decided to create a new consensus system with provable correctness. This effort, led by Prof. Mazières, is underway. His white paper and the accompanying code are expected to be released in a few months.

What happens when consensus was not reached: a fork in the ledger
Prof. Mazières’s research indicated some risk that consensus could fail, though we were nor certain if the required circumstances for such a failure were realistic. This week, we discovered the first instance of a consensus failure. On Tuesday night, the nodes on the network began to disagree and caused a fork of the ledger. The majority of the network was on ledger chain A. At some point, the network decided to switch to ledger chain B. This caused the roll back of a few hours of transactions that had only been recorded on chain A. We were able to replay most of these rolled back transactions on chain B to minimize the impact. However, in cases where an account had already sent a transaction on chain B the replay wasn’t possible.
We are still investigating the triggers for this consensus failure, but believe it is caused by the innate weaknesses of the Ripple/Stellar consensus system outlined above compounded by the number of accounts in the network. Presently, we have approximately 140,000 active accounts a week and over 3 million total accounts which is in excess of the approximately 120,000 total accounts (active and inactive) this stack has previously supported.
Our monitoring of the network has made it clear that the underlying Ripple/Stellar consensus system is not performing at this level of scale, which is still small relative to the global financial system. In order for such protocols to perform at real-world levels with the expected degree of safety, this number of accounts should not be a problem.

Future actions: steps to building a consensus algorithm that can withstand a meaningful level of activity

  • One validator node to ensure no ledger forks: This situation has led us to believe it is no longer safe to run the existing Ripple/Stellar consensus system with more than one validating node because doing so would expose funds in the network to potential double spends and ledger forks. To ensure no ledger forks going forward in Stellar, we have decided to temporarily only run one validating node until the new consensus algorithm is live. Therefore, like the previous partial payments flag issue, this risk will no longer exist in Stellar.

  • Prioritization of development resources: Given this real world occurrence of the consensus system’s previously theoretical risks, it is clear that we must prioritize the development of the new Stellar consensus algorithm and move away from the legacy consensus system to increase safety. The new Stellar consensus algorithm will not only be provably correct but also prioritize safety and fault tolerance over guaranteed termination. We believe this is a better choice since it is preferable for the system to pause than to enter divergent and contradictory states. You can keep abreast of progress on this via our Github.
If you have questions about what this means for your implementation, please feel free to email us at tech@stellar.org.

Read More Read More, Posted by: Risa
Eva GantzDecember 3, 2014
Interesting and innovative stories in #fintech.
Bionym introduced a wearable that uses a heartbeat as a PIN. Says Bionym CEO and founder Karl Martin, “the key thing we are offering here is this concept of persistent trust. The idea that if you are paying with your phone, you are still having to do something to prove who you are, whether it be with a fingerprint or a PIN. By wearing something, it can persistently know who you are, and interactions like payments or unlocking your devices can become completely seamless.”

   

Ars Technica explores the potential effects of the US’s semi-forced adoption of chip-and-PIN card authentication. “Starting in October 2015, payments received via the old way—via magnetic strip—will not receive any form of fraud prevention, meaning the merchant will have to eat any costs for fraudulent charges. Since lower-budget retailers will need to upgrade their POS tech to comply with this update, they will be far more likely to add in mobile payment compatibility.
View image on Twitter
   

In the wake of Apple Pay’s launch, Financial Brand discusses what will be needed to facilitate widespread adoption of mobile finance. “The most promising benefits of Apple Pay, in the context of mobile payment acceptance overall, is that the new Apple offering solves two of the biggest hurdles mobile payments adoption among consumers—lack of interest and security concerns.”
View image on Twitter
   

Industry leaders including representatives of Visa and Wells Fargo, discussed the future of Apple Pay at the Money2020. Their predictions included in-app payments:
“Smith from Wells Fargo predicted that consumers will use Apple Pay from a browser first, because that is the way they are used to shopping. The in-app use will be an interesting space in the long term.

Fidor and Kraken announced their partnership to launch a “specialized bank for cryptocurrencies.” Says Kraken’s CEO Jesse Powell, ““We hope that in opening up our relationship and expanding our circle of trust, we’ll see the industry grow, regulators become more comfortable and other banks thaw out.
View image on Twitter
   

Michael Ide at ValueWalk theorizes about the future of financial tech. He identifies “the potential of real-time, non-retail payment processing” as an area ripe for expansion
View image on Twitter
   

Business Korea argues that “Government regulations are too tight in the sectors with growth potential,” and overly rigid regulations must be lifted for fintech to further advance.+
Thumbnail for Regulations on Fintech Companies Need to be Eliminated

Ali Jiwani of The Royal Bank of Canada’s Payments Innovation Group presents three predications on the future of payments
View image on Twitter
   

Read More Read More, Posted by: Risa
Eva GantzNovember 18, 2014
Team
We’ve welcomed Bartek Nowotarski to the team! Bartek is joining the Platform team, and prior to Stellar, he worked as a lead developer and a security consultant. Learn more about Bartek here.
Technical
  • Wallet v2, reset recovery code feature, and two-factor authentication are now live for all users.

  • We refactored the send pane to increase performance and fix some user-reported bugs.

  • We made a change to the remove anchor function—you can now remove trustlines from an anchor.
Happenings
  • Our own Joyce Kim spoke on a panel at Money 2020 on “Economic Development in the Exponential Age.”
    View image on Twitter

       

  • She also gave a presentation on Stellar at the Bill & Melinda Gates Foundation, Financial Services for the Poor program.
       
  • We have a new and improved developers page.

Read More Read More, Posted by: Risa
Scott FleckensteinNovember 17, 2014
Recently, we here at the SDF launched the second version of our wallet server, a faster and more secure solution for encrypting and storing your wallets. I want to talk to you about the technical details behind why we have switched to version two (v2) so soon after launch and some of the design decisions we made while developing it. But before we get there, let me first tell you about what the wallet server even is.

Securing your Keys
Stellar, like every cryptocurrency that I am familiar with, is reliant upon public-key cryptography; you post transactions signed by your secret key that others can verify with your public key. The rub is that your private key is long by human standards, too long to remember. In stellar, we useed25519 to sign transactions, meaning that the private key seed is 32 bytes long.
Since your private key is so long, we would prefer to store it somewhere so that you don’t have to type it into the Stellar client every time you want to make a payment. The wallet server is that storage. Only you should be given access to your secret key, so that means that we need to devise a storage system where the SDF cannot access your secret key — and even more importantly — an attacker (someone who wants to steal your money) cannot access your secret key.
To accomplish this, both versions of our wallet server use this basic security design: encrypt your stellar wallet so that only you can decode it, and furthermore protect access to that encrypted wallet so that attackers cannot perform an offline dictionary attack. In both versions of our wallet server, your wallet is encrypted using AES with a 256-bit key in GCM Mode, so we will leave that aside for now.
The interesting bits of both designs are in how we protect access to your encrypted wallet and in how we derive the AES key to unlock your wallet. In this post, we’ll look at the former. Let’s look at the design of both wallet version one and version two in turn.

Wallet v1: scrypt(u+p, u+p)
Don’t worry if the equation above is gibberish now; we’ll get to that in time. Before we do, I should talk about one curious design goal we had for protecting access to the encrypted wallet in v1 that is absent in wallet v2 (reasons why will be explained below). In v1, we wanted to anonymize encrypted wallets such that only someone who knew both the username and the password for an account could find the encrypted wallet even if they had complete access to our database. This was to prevent an attacker from specifically targeting a high balance account, which is pretty trivial to find since the stellar ledger is public.
To accomplish this, we did not store usernames in the v1 tables. Instead, we stored encrypted wallets in a slot that was looked up by a value derived from both the username and password which we called the “Wallet ID”. Before we can talk about what goes into a wallet id, we should first discuss some basic cryptographic principles.

Hashing, Key Stretching and You
In cryptography, hashing a value is a central and recurring concept. In very simplified terms, hashing (amongst other things) can be used to verify a secret without storing it. This is especially useful when applied to a password: a server can keep a hash of your password which it can use to verify you know the password, but the server itself does not know your password. This is good, because in fact there are numerous instances of passwords being stolen because the service provider stored passwords in plaintext.
So, we want to hash your password so that it cannot be stolen, but it turns out hashing is not enough! As described in Coda Hale’s excellent post, most cryptographic hash functions are designed to be fast, and thusly are vulnerable to a dictionary attack, where the attacker tries billions of passwords to try to find the same hashed value. To prevent this, we use a key stretchingfunction to increase the computational cost of each password attempt. One such function isbcrypt, mentioned in Coda’s article that (namedrop) is co-authored by our Chief Scientist, David Mazières.

In the case of Stellar, we rely upon scrypt for our key stretching function.

Back to Wallet v1
Okay, so let’s get back to how Stellar protects access to your encrypted wallet. As mentioned, we stored encrypted wallets on the server in slots identified by a Wallet ID. If you presented a correct Wallet ID to a server, we would give you back the encrypted wallet for that ID. Simple as that. The equation in the section heading above (scrypt(u+p,u+p)) describes how we derived the Wallet ID: We used a concatenation of the username and password as both the passphrase and the saltpassed into scrypt. This Wallet ID is a one-way transformation and you cannot go from a Wallet ID back to the original username and password; this is the way we achieved anonymization on the server side.
Unfortunately, this anonymization comes with a several drawbacks that we had not anticipated at the original time of development. Since the login process of our wallet server is only presented with a single value (the Wallet ID), we cannot restrict the number of login attempts against a single user account: We don’t even know the username at that point! The only option we have is to restrict the number of login attempts by IP address. Additionally, not knowing the username at the time of login would prevent us from providing our improved implementation of two-factor authentication, which I describe below.
Now that we’ve looked some at Wallet v1, lets take a look at v2.

Wallet v2: hmac-sha256(“WALLET_ID”, scrypt(p,V+s+u))
Now that we’ve looked at the design for wallet v1, we can discuss v2 and why it’s an improvement. In the context of protecting access to your encrypted wallet, v2 has a veritable plethora of improvements: More expected use of cryptographic primitives, greater efficiency on the server side, better support for two-factor authentication, better future-proofing, and better protection against online dictionary attacks. Quite the list! Let’s go through each of them, but first let me describe the algorithm at a high level.
With wallet v2, login is now a two step process. First, you enter the username you would like to login with, and then you enter the password (and optionally the TOTP code) for your account. After the step where you enter your username, we communicate with the server to retrieve your “login parameters”: what salt to use, what scrypt parameters to use, and whether or not the provided user has enabled two factor authentication. After we’ve retrieved your login parameters, we can collect your password and go about deriving the keys used to retrieve your encrypted wallet.
We must derive two values: 
[code]K_m[/code]

, the master key and 

[code]W[/code]

 the wallet ID. 

[code]K_m[/code]

 does not get used directly; instead, we use it to derive child keys (such as 

[code]W[/code]

) that do get used directly within the protocol. To create 

[code]K_m[/code]

, we use your password 

[code]p[/code]

 as the “passphrase” argument to scrypt, and we use a combination of a version byte 

[code]V[/code]

, the random salt 

[code]s[/code]

 and your username 

[code]u[/code]

 as the “salt” argument to scrypt. As with v1, 

[code]W[/code]

 is used to authenticate access to your encrypted blob. We derive 

[code]W[/code]

 by using 

[code]K_w[/code]

 as the key for the HMAC-SHA256 computed over the constant string “WALLET_ID”.

As an aside, the Wallet ID used in v2 has no uniqueness constraint in our database like it does in v1. This is to prevent a very specific attack, which I may write about in the future.
If you recall from v1, we feed the username+password pair into scrypt as both the passphrase and the salt. Some of you who are more skilled in cryptography than I may have raised your eyebrows in curiosity when reading that; I know Prof. Mazières did when I initially explained the design to him. The reason? This family of functions was not designed to have the same input for both passphrase and salt. That’s not to say that it is specifically insecure in the case of scrypt, but in cryptography it’s better to be safe than sorry and it’s better to use these functions in the ways they were intended.
When it comes to server efficiency, v2 is orders of magnitude faster. In our tests on my laptop, an average login attempt in v1 takes 130ms. In v2? 6ms. The chief reason for this gain in efficiency comes from the removal of the server-side scrypt operation. Instead, we use a simple SHA-256 function to hash 
[code]W[/code]

 for storage in the database. To compensate for this your browser does more work in the initial scrypt operation to derive 

[code]K_m[/code]

. By reducing the work that needs to be done on the server, we will be better able to survive denial of service attacks and ensure that the CPU cycles investing in login directly contribute to frustrating brute-force attackers.

Two Factor Authentication (2FA) is a big deal and when properly set up it greatly increases the security of your account. If you haven’t done so on your stellar account already, and you own a smartphone, I highly recommend you go set it up now. It’s all right, I’ll wait… Okay, now that we have that out of the way, let me talk about how we do it differently. In many applications, your second factor of authentication happens after you’ve correctly entered your password, but in our implementation you actually enter your password and your 2FA code at the same time. That may not seem like a big change, but the benefit is: when 2FA is enabled with us, an attacker cannot use our wallet server to confirm that they know your password.
For example:
Say you use the same password for your stellar wallet as you do with another website. If that website is compromised and an attacker gets hold of your credentials, it’s simple for them to steal your funds, provided you don’t have 2FA enabled. If, however, we had a typical 2FA implementation the attacker wouldn’t be able to steal your funds but would be able to confirm that yes, you use the same password on both sites. Their next step would be to work on getting your 2FA authentication disabled (usually using some form of social engineering). You can read about one recent high-profile example here. With our implementation of two-factor authentication, an attacker would need to make one million HTTP requests in a 60 second window to confirm a single password. That is practically impossible. The downside to verifying the password and 2FA simultaneously is that attackers can now tell which accounts have enabled 2FA. So all the more reason for you to go an enable 2FA now!
Computers continue to get faster and faster every year. With that increase in power, scripts that attempt to brute force passwords or reverse a hash get faster as well. As argued in A Future-Adaptable Password Scheme (pdf link), it is vastly preferred that the cost of our method to secure passwords grows along with the increases in computational capacity. To accommodate this, scrypt has a work factor that we can tune to increase the cost of every operation. In v2, we have built in the ability to increase that work factor over time, so that as computers get faster we stay secure. In v1, we were prevented from adding this capability into the system due to the way we anonymized wallets.
The last area of improvement I’ll talk about today concerns online dictionary attacks, and how the second version of our wallet server will let us better protect against them. While there are many ways that someone can steal your password, one often used method is to simply try to login with many different passwords. As mentioned in the v1 section, the only tool we have available to us is to restrict login attempts by IP Address. In v2, the situation is improved. We can:
  • fight attacks by restricting login attempts by IP address

  • track when an attack is occurring on a specific account

  • fight attacks on a specific account by restricting login attempts by username

  • prevent denial of service attacks to a single account by adding whitelisted IP addresses on a per account basis

In Conclusion
Hopefully you have a better understanding about the design of our second wallet server. It’s better on a number of fronts: more featureful, more future-proof, more efficient, and more secure. By sacrificing anonymity of encrypted wallets, we enabled two factor authentication and upgradeable security. For the future, the launch of wallet v2 will enable us to add many more security features to help keep your funds safe.

On the next episode of “Scott rambles about technical things”
For part two of this series on the technical designs of wallet v2, we’ll delve into how we decrypt your wallet in the browser. Following shortly afterwards, we will also be publishing a whitepaper that provides a clear, concise specification for this entire protocol.

Read More Read More, Posted by: Risa
Bekki Bolthouse and adminNovember 17, 2014
Wallet version two (v2) is now live for all users. Your wallet will automatically be migrated to v2 upon login. You can read up more about the new features in wallet v2 here.
For a deep dive into the technical details behind why we have switched to v2 so soon after launch, please read Scott Fleckenstein’s blog, Wallet Server, Version Two: The Electric Boogaloo.
Also new today, we’ve added the ability to reset your recovery code. If you have lost your recovery code, you can now reset and activate a new code in the settings menu. We recommend that all users take this step to insure account access in the event of a lost password. This feature requires a verified email and that the “SEND EMAILS” setting is toggled to “on.”
[Image: wallet-v2-settings.png]
Additionally, two-factor authentication now available.
By using an app on your phone (such as Google Authenticator or Authy), you can prevent attempts at guessing your password. Two-factor authentication can be enabled in the settings menu.

Read More Read More, Posted by: Risa
Bekki Bolthouse and adminNovember 17, 2014
We’re rolling out a brand new version of the Stellar wallet this week and wanted to give you a heads up on the upcoming changes.
Wallet v2 is similar to the first version, but improved in the following ways:
– Better performance: faster and more efficient on the server side
– More secure: better protection from targeted wallet attacks
– Two Factor Authentication (2FA): stop an attacker who guesses your password

As a result of this wallet upgrade, users with an activated recovery code will need to do a quick update: log into your account and follow the prompts to reset your recovery code. That’s it!
[Image: high-quality-warning-reset-1.png]
Once you opt into the 2FA feature, use an app such as Google Authenticator or Authy to add a second layer of security to wallet authentication.
[Image: 2fa-higher-quality.png]
We will be rolling out the upgraded wallet v2 this week. Keep an eye out and let us know if you have any questions.

Read More Read More, Posted by: Stroopy
Eva GantzNovember 14, 2014
We’ve gathered up the latest most interesting stories in financial inclusion technology. Did we miss anything? Tweet us at @StellarOrg.
Know Your Customer (KYC) is a fairly standard compliance to prevent money laundering. Though it is argued to make digital currency safer for some users, does it exclude others?
HSBC CEO Stuart Milne argues that in developing nations “the stringent KYC norms will ensure that banks do financial exclusion rather than financial inclusion.”
View image on Twitter
   

The Alliance for Financial Inclusion (AFI) presents three different perspectives from digital financial inclusion policymakers: African, Latin American, and the Pacific Islands. Insights come from the Global Policy Forum (GPF) and the Digital Financial Services Working Group.
The Guardian’s Global Development Professional Network facilitated a a live Q&A attempting to answer the important question “How do we promote responsible practices in financial inclusion while supporting innovation?” Paneslists included Elisabeth Rhyne, Managing Director at the Center for Financial Inclusion and Erin Steinhauer, Vice President of global financial inclusion at Visa.
View image on Twitter
   

Despite India’s efforts at financial inclusion (namely the Jan Dhan Yojana scheme), new research reveals that the policies aren’t reaching many of the people whom they’re meant to help. From the Center for Financial Inclusion:
“A group of mystery shoppers to pose as low-income customers interested in opening a BSBDA at 42 branches of 27 large banks in metropolitan Chennai.
None of the 42 bank branches visited offered a BSBDA as a first suggestion to the mystery shoppers. And even after the auditors pressed further, using key verbal prompts such as ‘basic’, ‘an account with no charges’, etc., only 14 percent of banks revealed the existence of BSBDA. […] Clearly the amount of time and energy required to access BSBDAs is quite high for potential clients and likely acts as a strong barrier to access.”
View image on Twitter
   

CEO of Nofiatcoin and XNFTrading.com Robert Reyes announced a digital currency startup haven that will work with the Dominican Republic government & financial regulators. His goal is “to create a home for our sector with clear rules that will allow any young DC [digital currency] startup to set up shop and grow without much costs.”

Read More Read More, Posted by: Stroopy
Eva GantzOctober 30, 2014
This update is packed with information:
Technical
  • Trading history is now live in production – on the trading view, there is a new tab to the right of the order book tab.

  • Over the past 2 weeks, we have been doing a lot of work on the FB auth system and have significantly improved our spam detection filters. We are writing a blog post on our findings and results so keep an eye out for that.

  • Users can now specify their secret key during registration: Github and Roadmap.

  • Wallet V2 is almost ready (makes the wallets more secure and stable). It will include a required migration to the new system which will be as easy as one click. We will announce more details once we get closer to pushing it live.

  • You can now upvote on items on the live platform roadmap and we are publishing previews of new designs.

  • You can now delete accounts via the API – documentation is here.
Happenings
  • Prospress announced a free WooCommerce plugin that allows any merchant on WooCommerce to accept payments on the Stellar network – and it looks pretty spiffy!
    Stellar for WooCommerce from Prospress, Inc. on Vimeo.



  • RevealCoin just launched with a fascinating business model. They are issuing their own currency which they will give to their users as a means of sharing revenue – interesting stuff!
    [Image: Reveal_-_Share__Earn__Explore-300x195.jpg]

  • We added “Community” Cards to the roadmap. You can see many ways to contribute to the Stellar ecosystem, including non-technical things like helping translate knowledge center articles.
  • Stellar will be speaking at Money20/20 next week in Las Vegas. We are on the Disruptive Financial Inclusion Track, Economic Development in the Exponential Age Panel on Sunday, Nov 2 at 3:50 pm so if you want to connect at the conference, drop us a line at hello@stellar.org. And they made this great sketch of Joyce.
[Image: Joyce_Kim___Money20_20.png]
link

https://player.vimeo.com/video/109090976

Read More Read More, Posted by: Stroopy
Eva GantzOctober 14, 2014
Team
It has been a busy month for us on team growth. This past week, Bekki Bolthouse joined Stellar as our project manager from Rackspace. Bekki has already jumped right in with publishing our Platform team roadmap and she will also be in charge of making sure lines of communication are always open between developers in the open-source community and the Foundation.

Technical
  • Giveaway auth algorithm has been updated and will continue to be updated. You can read more about it here.

  • Partial payments has been removed. You can read more about it here.

  • Feel free to check out the Platform roadmap that Bekki released. Now, you can look there and at our standup recaps in IRC to see what is being actively worked on.

  • Analytics: We have begun to implement new analytics tools to work with anomaly detection for the giveaway auth algorithm. If you want to be outside the analytics, feel free to create a wallet with no email address and block cookies on the client.

  • New features pushed by open-source developer m-casey: Thanks for contributing one-click highlight of Stellar addresses and an idle logout setting for users.

Happenings

Read More Read More, Posted by: Stroopy
Joyce KimOctober 12, 2014
Direct Signup Program’s Algorithm
We are releasing a spam detection update to the Direct Signup program’s authentication system today. Although we would like to let in as many people as possible right off the bat, we do need to make sure that we are on the road towards our educational goals. To accomplish this, we need to always 1) improve the content (also in progress) and 2) make sure that participants are learning as they go through the program. This means we will continually be taking measured, iterative steps to improve the program. Stellar has been around for less than three months, so it is still in the early days.
We have opted to take a conservative approach to the authentication system and increase the requirements needed for an account to be considered legitimate. This will mean that the number of false negatives (real users who cannot gain access) will increase.
For all the users who fall into this false negative category, we apologize for the inconvenience and ask that you come back at some point in the future to try again as we will be continually fine-tuning the algorithm to be smarter and more accurate.

Invite System Info
As we announced previously, we will be rolling out an invite system to allow community members to invite friends to the system. We have been slowly testing the invite system with small batches of users as some of you have seen.
Based off the learnings from the invite system tests and other community concerns about bad accounts, we have developed our own algorithm for determining which accounts will receive invitations and the invite algorithm, like our spam account filter, will constantly evolve and be made smarter with new data.
We will also be conservative with the invites and only a small percentage of users will receive them at any given time. And unfortunately, this means that not every account will receive invites even if they are a real and active user. Emailing us or tweeting asking for invites will not help or cause you to get invites. We ask that people be understanding about this.
For those community members who receive invites, it would be great if you could share your own experiences and thoughts about Stellar with whomever you end up inviting. You can also share theLearn page with them (we will be releasing a newer version of it soon as well).

Read More Read More, Posted by: Stroopy
Joyce KimOctober 11, 2014
This week, we learned of an issue related to a payment setting feature known as “partial payments” that existed in the legacy code base of the Stellar protocol. As it exists in the Ripple code base, partial payments allow a user to send a small part of a payment rather than the entire payment. For example, the sender could tell the anchor that s/he was sending 10 BTC while actually only sending .0001 BTC. This feature is rarely, if ever, used in practice. Normally, an anchor must check the “Amount” field to determine how much they received as it is the only field returned. However, in the case of a partial payment transaction, the “DeliveredAmount” field appears and the anchor must check the “DeliveredAmount” field instead. If an anchor or other entity is unaware of this setting, it could result in loss of funds.
On Oct 8, we informed all known anchors of this issue then updated the Stellar code base to remove this feature, as it added unnecessary complexity for little value on a protocol level. This particular issue no longer exists on the Stellar network.
We are in the process of preparing integration documents for Stellar. If you have any feedback or suggestions for things we should include, please feel free to send them along to us at hello@stellar.org or via issues on our Github for documentation.

Read More Read More, Posted by: Stroopy
Joyce KimOctober 7, 2014
Team:
Happy to announce that Eva Gantz has joined the Stellar team working on community so you will be seeing her around Twitter, FB and other online channels. Prior to joining us, she has worked on social strategy for an LGBTQ publishing house and has run a site to assist authors with their own social media strategy. You can read more about her here.
New Features:
Trading is now live on the client! This gives people easy access to the global distributed exchange. It allows you to trade any currency for any other. As it is a feature for more advanced users, you must first enable it in your settings. Take a peek here:
[Image: stellar-1024x855.png]
More Happenings:
  • New BTC anchor: onecred.com launched with no-login BTC-STR anchor.

  • We have started posting weekly recaps of Stellar Development Foundation’s standups in the stellar-dev IRC chat. The goal is to provide more transparency for the public into what is being worked in by each team member.

  • We have completed setup of Zendesk to help us stay on top of the inbound community requests we have been getting. As many of you know, roughly 100X more people ended up signing up for Stellar our first month than we had anticipated which lead to a deluge of emails, tweets, forum posts, phone calls and IMs. Now that we have the system in place, we have spent the past week going through the backlog – still a lot more to go, but progress is being made!

  • We also added some more FAQs and will be adding more over the next few weeks.

  • Relatedly, there are now over 2 million Facebook auths for stellars!

  • Winnie has begun doing a series of 1:1s conversations with community members to listen to how they are participating in the ecosystem and their envisioned future for Stellar.

  • Impromptu Stellar gathering in NYC: Winnie and I ended up in NYC this week and tweeted out a last minute gathering. It was so great hearing about everyone’s unique stories about why Stellar is meaningful to them and also learning about their projects.
   

Read More Read More, Posted by: Stroopy
Jed McCalebSeptember 26, 2014
Summary:
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
Causes:
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 “status.stellar.org” 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 security@stellar.org—thank you.

Read More Read More, Posted by: Stroopy
Joyce KimSeptember 18, 2014
Team
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.
Happenings
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

Team
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: Usestellar.org

  • You can now top up prepaid mobile minutes in over 100 countries using stellars onpiiko.com. 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

FINANCE with a MISSION to FIGHT POVERTY


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