Knowledge Base

Networking Protocols

Wikipedia Entry


Skywire Nodes

The building blocks of the Skywire network, deployable by anyone to ensure decentralization of the Skywire ecosystem.

[this portion needs to be expanded on]

Skycoin Nodes

[this portion needs to be expanded on]

Paper Wallet

Bitcoin Wiki Entry

Paper wallet

Water damaged paper wallet

A paper wallet is the name given to an obsolete and unsafe method of storing bitcoin which was popular between 2011 and 2016. It works by having a single private key and bitcoin address, usually generated by a website, being printed out onto paper.

This method has a large number of downsides and should not be used[1][2].

For storage of bitcoins, a much better way accomplish what paper wallets do is to use seed phrases instead, where the user writes down 12 or 24 random words generated by their wallet.

Paper wallet flaws

Printing is problematic

Paper wallets require using a printer to transfer them to paper. Many printers have a hard drive for internal storage where the paper wallet will be saved. Anybody who reads the file will be able to see the private key and steal the stored bitcoins. Shared printers such as in schools, offices or internet cafes are also usually centrally logged. If the printer is accessed over WiFi then any radio wave listener could also obtain the private keys and steal the money.[3]

Seed phrases avoid this problem by having the user transfer the sensitive information to paper without a printer but via their own handwriting.

Promotes address reuse

Paper wallets have just one bitcoin address, so they promote address reuse. The paper wallet creating websites generally have no warnings against this.

Deterministic wallets and seed phrases avoids this problem by being able to create a new bitcoin address for every incoming transaction.

Encouragment of centralized and outsourced validation

Despite the name, paper wallets are not actually wallets. They only store the private keys and addresses, and cannot tell users if they have actually received bitcoins and in what quantity.

The single bitcoin addresses require the user to have random-access lookups of any address on the blockchain, this requirement pushes users to use centralized third-party blockchain explorer websites. This results in privacy and validation issues, the websites can spy on users and lie to them.

A more private solution is to import the private key into bitcoin-qt and rescan. Nobody watching the bitcoin-qt full node from outside will be able to tell which address it's interested in because all the scanning happens locally on disk. Unfortunately rescanning is not scalable and so is very slow; therefore most users are pushed towards using public blockchain explorers or Electrum servers. These centralized services can spy on the user and learn exactly how many bitcoins they have and where they spend them. An address database created from all bitcoin addresses is nearly 20 GB in size at of October 2018 and takes a long time to build up, so very few people will have this kind of thing available locally for the few occasions when they redeem paper wallets. Almost all wallet software today especially smartphone wallets relies on centralized lookups when redeeming paper wallets.

Deterministic wallets and seed phrases partly avoid this problem by having a sequence of bitcoin addresses which can be sequentially scanned. Wallets using that tech don't inherently need any extra databases and are compatible with pruning.

See Also: Full_node#Why_should_you_use_a_full_node_wallet

Raw private keys are dangerous

Dealing with raw private keys is very unintuative and has lead to loss of funds on a number of occasions.[4][5]. Paper wallets encourage these dangers by only having one private key and exposing it to the user.

One example is the mistake of destroy a paper wallet after it's imported into a deterministic wallet, thinking that it has become a part of the deterministic wallet and it's safe to destroy because the master seed of the deterministic wallet has been backed up. In reality the private key is not part of the deterministic wallet. If the paper wallet (the paper) is destroyed and the app is uninstalled, the BTC is gone even if the deterministic wallet is recovered from its master seed. The unintuative behavour of raw private keys leads to this.

Using only fully-featured wallet software is a much better because it only presents with intuative interfaces (like a GUI button to Send) which abstracts all the dangerous details away from the user.

Change addresses are not handled which leads to screwups

Users have been known to import the private key into software wallet and then spend part of the funds. They mistakenly believe the remaining funds are still on the paper wallet when in reality they are in a change address.[6]

Encouragement of raw transactions

Raw Transactions are dangerous, unintuitive and have many times resulted in loss of funds.

A notable example of such a costly mistake is the address 1Acbo3viCYy1TSZB7m2W1nPPNF4rcAPMC9 which seems to have been a paper wallet. The owner appears to have been regularly buying bitcoin between April 2014 and January 2017, before apparently making a mistake with raw transactions and sending 50 bitcoins as miner fees.[7] (worth about $50000 at the contemporary exchange rate).

Also note the terrible privacy due to Address reuse that allows us to get such a complete picture of what happened.

Low error correction

Water damaged paper wallet private key

The private keys is typically printed in rather small font. Sometimes the characters could be mistakenly read for another letter, such as a B versus an 8 or 1 versus l. If even a single character is wrong or mistakenly typed then the entire private key will be invalid. Private keys in WIF format have a checksum but there are no tools for regular users to correct mistakes.

QR codes were not designed for secure storage of cryptographic material. QR codes have been damaged and made unscannable by water[8][9], crumpling and even folding the paper.

As seed phrases uses natural language words, they have far more error correction. Words written in bad handwriting can often still be read. If one or two letters are missing the word can often still be read. The word list from which seed phrase words are drawn from is carefully chosen so that the first four letters of a word is enough to uniquely identify it.

Inconsistent private key format

The spending of paper wallets relies on wallet software understanding the private key format. There has been at least one situation where an update to private key formats resulted in a user's funds becoming stuck [10].

Seed phrases avoid this problem because they are created by the same wallet software which understands how to spend from them.

Encouragement of obsolete brainwallet style

Almost all paper wallet websites today also have an interface to the obsolete sha256 brainwallets. These are very insecure and should never be used, yet paper wallet websites do not come with adequate warnings.

See also: Brainwallet#Obsolete_Brainwallet_Style

Javascript software

Most paper wallets are created in a website using Javascript cryptography, which is considered unsafe for anything related to bitcoin.

Browser wallets are bad

Almost all paper wallets are made by websites, which therefore involves most of the problems associated with Browser-based wallet.[11][12]

Redeeming bitcoins and withdrawing funds

Casascius holding early paper wallets

The best way to redeem the bitcoins from a private key is to use the "sweep" feature of certain wallet software. This sends the entire balance of the paper wallet to a deterministic wallet. Alternatively the private key could be imported and the entire balance sent to an address in the wallet.

There are various wallets for doing this:

Bitcoin ATMs and paper wallets

Many bitcoin ATMs use a paper-wallet-like system for delivering bitcoins if the customer doesn't have a bitcoin wallet. The ATMs can print out a private key/address pair onto paper which contain the customer's bitcoins. Ideally the customer would sweep the bitcoins into their own wallet as soon as they can.

See Also



A route is a path for network traffic. It consists of a set of hops that are done over transports. The term does not specify what kind of transports are used.


Built-in end-to-end virtual private encryption over the Skywire network to ensure privacy.

Wikipedia Entry

Software-defined networking

Software-defined networking (SDN) technology is an approach to network management that enables dynamic, programmatically efficient network configuration in order to improve network performance and monitoring making it more like cloud computing than traditional network management.[1] SDN is meant to address the fact that the static architecture of traditional networks is decentralized and complex while current networks require more flexibility and easy troubleshooting. SDN attempts to centralize network intelligence in one network component by disassociating the forwarding process of network packets (data plane) from the routing process (control plane). The control plane consists of one or more controllers which are considered as the brain of SDN network where the whole intelligence is incorporated. However, the intelligence centralization has its own drawbacks when it comes to security,[1] scalability and elasticity[1] and this is the main issue of SDN.

SDN was commonly associated with the OpenFlow protocol (for remote communication with network plane elements for the purpose of determining the path of network packets across network switches) since the latter's emergence in 2011. However, since 2012[2][3] OpenFlow for many companies is no longer an exclusive solution, they added proprietary techniques. These include Cisco Systems' Open Network Environment and Nicira's network virtualization platform.

SD-WAN applies similar technology to a wide area network (WAN).[4]


The history of SDN principles can be traced back to the separation of the control and data plane first used in the public switched telephone network as a way to simplify provisioning and management well before this architecture began to be used in data networks.

The Internet Engineering Task Force (IETF) began considering various ways to decouple the control and forwarding functions in a proposed interface standard published in 2004 appropriately named "Forwarding and Control Element Separation" (ForCES).[5] The ForCES Working Group also proposed a companion SoftRouter Architecture.[6] Additional early standards from the IETF that pursued separating control from data include the Linux Netlink as an IP Services Protocol[7] and A Path Computation Element (PCE)-Based Architecture.[8]

These early attempts failed to gain traction for two reasons. One is that many in the Internet community viewed separating control from data to be risky, especially owing to the potential for a failure in the control plane. The second is that vendors were concerned that creating standard application programming interfaces (APIs) between the control and data planes would result in increased competition.

The use of open source software in split control/data plane architectures traces its roots to the Ethane project at Stanford's computer sciences department. Ethane's simple switch design led to the creation of OpenFlow.[9] An API for OpenFlow was first created in 2008.[10] That same year witnessed the creation of NOX—an operating system for networks.[11]

Work on OpenFlow continued at Stanford, including with the creation of testbeds to evaluate use of the protocol in a single campus network, as well as across the WAN as a backbone for connecting multiple campuses.[12] In academic settings there were a few research and production networks based on OpenFlow switches from NEC and Hewlett-Packard; as well as based on Quanta Computer whiteboxes, starting from about 2009.[13]

Beyond academia, the first deployments were by Nicira in 2010 to control OVS from Onix, co-developed with NTT and Google. A notable deployment was Google's B4 deployment in 2012.[14][15] Later Google acknowledged their first OpenFlow with Onix deployments in their Datacenters at the same time.[16] Another known large deployment is at China Mobile.[17]

The Open Networking Foundation was founded in 2011 to promote SDN and OpenFlow.

At the 2014 Interop and Tech Field Day, software-defined networking was demonstrated by Avaya using shortest path bridging (IEEE 802.1aq) and OpenStack as an automated campus, extending automation from the data center to the end device, removing manual provisioning from service delivery.[18][19]


SDN architectures decouple network control and forwarding functions, enabling network control to become directly programmable and the underlying infrastructure to be abstracted from applications and network services.[20]

The OpenFlow protocol can be used in SDN technologies. The SDN architecture is:

  • Directly programmable: Network control is directly programmable because it is decoupled from forwarding functions.
  • Agile: Abstracting control from forwarding lets administrators dynamically adjust network-wide traffic flow to meet changing needs.
  • Centrally managed: Network intelligence is (logically) centralized in software-based SDN controllers that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch.
  • Programmatically configured: SDN lets network managers configure, manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs, which they can write themselves because the programs do not depend on proprietary software.
  • Open standards-based and vendor-neutral: When implemented through open standards, SDN simplifies network design and operation because instructions are provided by SDN controllers instead of multiple, vendor-specific devices and protocols.

The need for a new network architecture

The explosion of mobile devices and content, server virtualization, and advent of cloud services are among the trends driving the networking industry to re-examine traditional network architectures.[21] Many conventional networks are hierarchical, built with tiers of Ethernet switches arranged in a tree structure. This design made sense when client-server computing was dominant, but such a static architecture is ill-suited to the dynamic computing and storage needs of today's enterprise data centers, campuses, and carrier environments.[22] Some of the key computing trends driving the need for a new network paradigm include:

Changing traffic patterns
Within the enterprise data center, traffic patterns have changed significantly. In contrast to client-server applications where the bulk of the communication occurs between one client and one server, today's applications access different databases and servers, creating a flurry of "east-west" machine-to-machine traffic before returning data to the end user device in the classic "north-south" traffic pattern. At the same time, users are changing network traffic patterns as they push for access to corporate content and applications from any type of device (including their own), connecting from anywhere, at any time. Finally, many enterprise data centers managers are contemplating a utility computing model, which might include a private cloud, public cloud, or some mix of both, resulting in additional traffic across the wide area network.
The "consumerization of IT"
Users are increasingly employing mobile personal devices such as smartphones, tablets, and notebooks to access the corporate network. IT is under pressure to accommodate these personal devices in a fine-grained manner while protecting corporate data and intellectual property and meeting compliance mandates.
The rise of cloud services
Enterprises have enthusiastically embraced both public and private cloud services, resulting in unprecedented growth of these services. Enterprise business units now want the agility to access applications, infrastructure, and other IT resources on demand and à la carte. To add to the complexity, IT's planning for cloud services must be done in an environment of increased security, compliance, and auditing requirements, along with business reorganizations, consolidations, and mergers that can change assumptions overnight. Providing self-service provisioning, whether in a private or public cloud, requires elastic scaling of computing, storage, and network resources, ideally from a common viewpoint and with a common suite of tools.
"Big data" means more bandwidth
Handling today's "big data" or mega datasets requires massive parallel processing on thousands of servers, all of which need direct connections to each other. The rise of mega datasets is fueling a constant demand for additional network capacity in the data center. Operators of hyperscale data center networks face the daunting task of scaling the network to previously unimaginable size, maintaining any-to-any connectivity without going broke.

Architectural components

A high-level overview of the software-defined networking architecture

The following list defines and explains the architectural components:[23]

SDN Application
SDN Applications are programs that explicitly, directly, and programmatically communicate their network requirements and desired network behavior to the SDN Controller via a northbound interface (NBI). In addition they may consume an abstracted view of the network for their internal decision-making purposes. An SDN Application consists of one SDN Application Logic and one or more NBI Drivers. SDN Applications may themselves expose another layer of abstracted network control, thus offering one or more higher-level NBIs through respective NBI agents.
SDN Controller
The SDN Controller is a logically centralized entity in charge of (i) translating the requirements from the SDN Application layer down to the SDN Datapaths and (ii) providing the SDN Applications with an abstract view of the network (which may include statistics and events). An SDN Controller consists of one or more NBI Agents, the SDN Control Logic, and the Control to Data-Plane Interface (CDPI) driver. Definition as a logically centralized entity neither prescribes nor precludes implementation details such as the federation of multiple controllers, the hierarchical connection of controllers, communication interfaces between controllers, nor virtualization or slicing of network resources.
SDN Datapath
The SDN Datapath is a logical network device that exposes visibility and uncontested control over its advertised forwarding and data processing capabilities. The logical representation may encompass all or a subset of the physical substrate resources. An SDN Datapath comprises a CDPI agent and a set of one or more traffic forwarding engines and zero or more traffic processing functions. These engines and functions may include simple forwarding between the datapath's external interfaces or internal traffic processing or termination functions. One or more SDN Datapaths may be contained in a single (physical) network element—an integrated physical combination of communications resources, managed as a unit. An SDN Datapath may also be defined across multiple physical network elements. This logical definition neither prescribes nor precludes implementation details such as the logical to physical mapping, management of shared physical resources, virtualization or slicing of the SDN Datapath, interoperability with non-SDN networking, nor the data processing functionality, which can include OSI layer 4-7 functions.
SDN Control to Data-Plane Interface (CDPI)
The SDN CDPI is the interface defined between an SDN Controller and an SDN Datapath, which provides at least (i) programmatic control of all forwarding operations, (ii) capabilities advertisement, (iii) statistics reporting, and (iv) event notification. One value of SDN lies in the expectation that the CDPI is implemented in an open, vendor-neutral and interoperable way.
SDN Northbound Interfaces (NBI)
SDN NBIs are interfaces between SDN Applications and SDN Controllers and typically provide abstract network views and enable direct expression of network behavior and requirements. This may occur at any level of abstraction (latitude) and across different sets of functionality (longitude). One value of SDN lies in the expectation that these interfaces are implemented in an open, vendor-neutral and interoperable way.

SDN Control Plane

Centralized - Hierarchical - Distributed

The implementation of the SDN control plane can follow a centralized, hierarchical, or decentralized design. Initial SDN control plane proposals focused on a centralized solution, where a single control entity has a global view of the network. While this simplifies the implementation of the control logic, it has scalability limitations as the size and dynamics of the network increase. To overcome these limitations, several approaches have been proposed in the literature that fall into two categories, hierarchical and fully distributed approaches. In hierarchical solutions,[24][25] distributed controllers operate on a partitioned network view, while decisions that require network-wide knowledge are taken by a logically centralized root controller. In distributed approaches,[26][27] controllers operate on their local view or they may exchange synchronization messages to enhance their knowledge. Distributed solutions are more suitable for supporting adaptive SDN applications.

Controller Placement

A key issue when designing a distributed SDN control plane is to decide on the number and placement of control entities. An important parameter to consider while doing so is the propagation delay between the controllers and the network devices,[28] especially in the context of large networks. Other objectives that have been considered involve control path reliability,[29] fault tolerance,[30] and application requirements.[31]

SDN flow forwarding (sdn)

Proactive vs Reactive vs Hybrid[32][33]
OpenFlow uses TCAM tables to route packet sequences (flows). If flows arrive at a switch, a flow table lookup is performed. Depending on the flow table implementation this is done in a software flow table if a vSwitch is used or in an ASIC if it's implemented in hardware. In the case when no matching flow is found, a request to the controller for further instructions is sent. This is handled in one of three different modes. In reactive mode the controller acts after these requests and creates and installs a rule in the flow table for the corresponding packet if necessary. In proactive mode the controller populates flow table entries for all possible traffic matches possible for this switch in advance. This mode can be compared with typical routing table entries today, where all static entries are installed ahead of time. Following this no request is sent to the controller since all incoming flows will find a matching entry. A major advantage in proactive mode is that all packets are forwarded in line rate (considering all flow table entries in TCAM) and no delay is added. The third mode, hybrid mode, follows the flexibility of a reactive mode for a set of traffic and the low-latency forwarding (proactive mode) for the rest of the traffic.



Software-defined mobile networking (SDMN)[34][35] is an approach to the design of mobile networks where all protocol-specific features are implemented in software, maximizing the use of generic and commodity hardware and software in both the core network and radio access network.[36] It is proposed as an extension of SDN paradigm to incorporate mobile network specific functionalities.[37] Since 3GPP Rel.14, a Control User Plane Separation was introduced in the Mobile Core Network architectures with the PFCP protocol.


An SD-WAN is a Wide Area Network (WAN) managed using the principles of software-defined networking.[38] The main driver of SD-WAN is to lower WAN costs using more affordable and commercially available leased lines, as an alternative or partial replacement of more expensive MPLS lines. Control and management is administered separately from the hardware with central controllers allowing for easier configuration and administration.[39]


An SD-LAN is a Local area network (LAN) built around the principles of software-defined networking, though there are key differences in topology, network security, application visibility and control, management and quality of service.[40] SD-LAN decouples control management, and data planes to enable a policy driven architecture for wired and wireless LANs. SD-LANs are characterized by their use of a cloud management system and wireless connectivity without the presence of a physical controller.[41]

Security using the SDN paradigm

SDN architecture may enable, facilitate or enhance network-related security applications due to the controller's central view of the network, and its capacity to reprogram the data plane at any time. While security of SDN architecture itself remains an open question that has already been studied a couple of times in the research community,[42][43][44][45] the following paragraphs only focus on the security applications made possible or revisited using SDN.

Several research works on SDN have already investigated security applications built upon the SDN controller, with different aims in mind. Distributed Denial of Service (DDoS) detection and mitigation,[46][47] as well as botnet[48] and worm propagation,[49] are some concrete use-cases of such applications: basically, the idea consists in periodically collecting network statistics from the forwarding plane of the network in a standardized manner (e.g. using Openflow), and then apply classification algorithms on those statistics in order to detect any network anomalies. If an anomaly is detected, the application instructs the controller how to reprogram the data plane in order to mitigate it.

Another kind of security application leverages the SDN controller by implementing some moving target defense (MTD) algorithms. MTD algorithms are typically used to make any attack on a given system or network more difficult than usual by periodically hiding or changing key properties of that system or network. In traditional networks, implementing MTD algorithms is not a trivial task since it is difficult to build a central authority able of determining - for each part of the system to be protected - which key properties are hid or changed. In an SDN network, such tasks become more straightforward thanks to the centrality of the controller. One application can for example periodically assign virtual IPs to hosts within the network, and the mapping virtual IP/real IP is then performed by the controller.[50] Another application can simulate some fake opened/closed/filtered ports on random hosts in the network in order to add significant noise during reconnaissance phase (e.g. scanning) performed by an attacker.[51]

Additional value regarding security in SDN enabled networks can also be gained using FlowVisor[52] and FlowChecker[53] respectively. The former tries to use a single hardware forwarding plane sharing multiple separated logical networks. Following this approach the same hardware resources can be used for production and development purposes as well as separating monitoring, configuration and internet traffic, where each scenario can have its own logical topology which is called slice. In conjunction with this approach FlowChecker[52] realizes the validation of new OpenFlow rules that are deployed by users using their own slice.

SDN controller applications are mostly deployed in large-scale scenarios, which requires comprehensive checks of possible programming errors. A system to do this called NICE was described in 2012.[54] Introducing an overarching security architecture requires a comprehensive and protracted approach to SDN. Since it was introduced, designers are looking at possible ways to secure SDN that do not compromise scalability. One architecture called SN-SECA (SDN+NFV) Security Architecture.[55]

Group Data Delivery Using SDN

Distributed applications that run across datacenters usually replicate data for the purpose of synchronization, fault resiliency, load balancing and getting data closer to users (which reduces latency to users and increases their perceived throughput). Also, many applications, such as Hadoop, replicate data within a datacenter across multiple racks to increase fault tolerance and make data recovery easier. All of these operations require data delivery from one machine or datacenter to multiple machines or datacenters. The process of reliably delivering data from one machine to multiple machines is referred to as Reliable Group Data Delivery (RGDD).

SDN switches can be used for RGDD via installation of rules that allow forwarding to multiple outgoing ports. For example, OpenFlow provides support for Group Tables since version 1.1[56] which makes this possible. Using SDN, a central controller can carefully and intelligently setup forwarding trees for RGDD. Such trees can be built while paying attention to network congestion/load status to improve performance. For example, MCTCP[57] is a scheme for delivery to many nodes inside datacenters that relies on regular and structured topologies of datacenter networks while DCCast[58] and QuickCast[59] are approaches for fast and efficient data and content replication across datacenters over private WANs.

Relationship to NFV

NFV Network Function Virtualization is a concept that complements SDN. Thus, NFV is not dependent on SDN or SDN concepts. NFV disunites software from hardware to enable flexible network deployment and dynamic operation. NFV deployments typically use commodity servers to run network services software versions that previously were hardware-based. These software-based services that run in an NFV environment are called Virtual Network Functions (VNF).[60] SDN-NFV hybrid program was provided for high efficiency, elastic and scalable capabilities NFV aimed at accelerating service innovation and provisioning using standard IT virtualization technologies.[60][61] SDN provides the agility of controlling the generic forwarding devices such as the routers and switches by using SDN controllers. On the other hand, NFV agility is provided for the network applications by using virtualized servers. It is entirely possible to implement a virtualized network function (VNF) as a standalone entity using existing networking and orchestration paradigms. However, there are inherent benefits in leveraging SDN concepts to implement and manage an NFV infrastructure, particularly when looking at the management and orchestration of VNFs, and that's why multivendor platforms are being defined that incorporate SDN and NFV in concerted ecosystems.[62]

Relationship to DPI

DPI Deep Packet Inspection provides network with application-awareness, while SDN provides applications with network-awareness.[63] Although SDN will radically change the generic network architectures, it should cope with working with traditional network architectures to offer high interoperability. The new SDN based network architecture should consider all the capabilities that are currently provided in separate devices or software other than the main forwarding devices (routers and switches) such as the DPI, security appliances [64]

See also


  1. ^ a b c Benzekki, Kamal; El Fergougui, Abdeslam; Elbelrhiti Elalaoui, Abdelbaki (2016). "Software-defined networking (SDN): A survey". Security and Communication Networks. 9 (18): 5803–5833. doi:10.1002/sec.1737.
  2. ^ "Software-defined networking is not OpenFlow, companies proclaim".
  3. ^ "InCNTRE's OpenFlow SDN testing lab works toward certified SDN product".
  4. ^ "Predicting SD-WAN Adoption". 2015-12-15. Retrieved 2016-06-27.
  5. ^ L. Yang (Intel Corp.), R. Dantu (Univ. of North Texas), T. Anderson (Intel Corp.) & R. Gopal (Nokia.) (April 2004). "Forwarding and Control Element Separation (ForCES) Framework".CS1 maint: Multiple names: authors list (link)
  6. ^ T. V. Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani, and T. Woo (Nov 2004). "The SoftRouter Architecture" (PDF).CS1 maint: Multiple names: authors list (link)
  7. ^ J. Salim (Znyx Networks), H. Khosravi (Intel), A. Kleen (Suse), and A. Kuznetsov (INR/Swsoft) (July 2003). "Linux Netlink as an IP Services Protocol".CS1 maint: Multiple names: authors list (link)
  8. ^ A. Farrel (Old Dog Consulting), J. Vasseur (Cisco Systems, Inc.), and J. Ash (AT&T) (August 2006). "A Path Computation Element (PCE)-Based Architecture".CS1 maint: Multiple names: authors list (link)
  9. ^ Martìn Casado, Michael J. Freedman, Justin Pettit, Jianying Luo, and Nick McKeown (Stanford University) (August 2007). "Ethane: Taking Control of the Enterprise" (PDF).CS1 maint: Multiple names: authors list (link)
  10. ^ N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. (April 2008). "OpenFlow: Enabling Innovation in Campus Networks" (PDF).CS1 maint: Multiple names: authors list (link)
  11. ^ N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker. (July 2008). "NOX: Towards an Operating System for Networks" (PDF).CS1 maint: Multiple names: authors list (link)
  12. ^ "GENI. Campus OpenFlow topology". 2011.
  13. ^ Kuang-Ching “KC” Wang (Oct 3, 2011). "Software Defined Networking and OpenFlow for Universities: Motivation, Strategy, and Uses" (PDF).
  14. ^ Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, Subbaiah Venkata, Jim Wanderer, Junlan Zhou, Min Zhu, Jonathan Zolla, Urs Hölzle, Stephen Stuart and Amin Vahdat (Google) (August 12–16, 2013). "B4: Experience with a Globally-Deployed Software Defined WAN" (PDF).CS1 maint: Multiple names: authors list (link)
  15. ^ brent salisbury (May 14, 2013). "Inside Google's Software-Defined Network".
  16. ^ Arjun Singh, Joon Ong, Amit Agarwal, Glen Anderson, Ashby Armistead, Roy Bannon, Seb Boving, Gaurav Desai, Bob Felderman, Paulie Germano, Anand Kanagala, Jeff Provost, Jason Simmons, Eiichi Tanda, Jim Wanderer, Urs Hölzle, Stephen Stuart, Amin Vahdat (2015). "Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's Datacenter Network".CS1 maint: Multiple names: authors list (link)
  17. ^ ""MPLS-TP OpenFlow Protocol Extensions for SPTN" becomes a formal ONF standard by unanimous approval". June 27, 2017.
  18. ^ Camille Campbell (February 6, 2014). "Avaya Debuts Networking Innovations at 'Tech Field Day'".
  19. ^ Elizabeth Miller Coyne (September 23, 2016). "Huawei Exec: SDN's Become a 'Completely Meaningless Term'".
  20. ^ "Software-Defined Networking (SDN) Definition". Retrieved 26 October 2014.
  21. ^ "White Papers". Retrieved 26 October 2014.
  22. ^ Montazerolghaem, Ahmadreza.; Yaghmaee, M. H.; Leon-Garcia, A. (2017). "OpenSIP: Toward Software-Defined SIP Networking". IEEE Transactions on Network and Service Management. PP (99): 184–199. arXiv:1709.01320. doi:10.1109/tnsm.2017.2741258. ISSN 1932-4537.
  23. ^ "SDN Architecture Overview" (PDF). Retrieved 22 November 2014.
  24. ^ S.H. Yeganeh, Y. Ganjali, "Kandoo: A Framework for Efficient and Scalable Offloading of Control Applications," proceedings of HotSDN, Helsinki, Finland, 2012.
  25. ^ R. Ahmed, R. Boutaba, "Design considerations for managing wide area software defined networks," Communications Magazine, IEEE, vol. 52, no. 7, pp. 116–123, July 2014.
  26. ^ T. Koponen et al, "Onix: A Distributed Control Platform for Large scale Production Networks," proceedings USENIX, ser. OSDI’10, Vancouver, Canada, 2010.
  27. ^ D. Tuncer, M. Charalambides, S. Clayman, G. Pavlou, "Adaptive Resource Management and Control in Software Defined Networks," Network and Service Management, IEEE Transactions on, vol. 12, no. 1, pp. 18–33, March 2015.
  28. ^ B. Heller, R. Sherwood, and N. McKeown, "The Controller Placement Problem," proceedings of HotSDN’12, 2012.
  29. ^ Y.N. Hu, W.D. Wang, X.Y. Gong, X.R. Que, S.D. Cheng, "On the placement of controllers in software-defined networks," Journal of China Universities of Posts and Telecommunications, vol. 19, Supplement 2, no. 0, pp. 92 – 171, 2012.
  30. ^ F.J. Ros, P.M. Ruiz, "Five nines of southbound reliability in software defined networks," proceedings of HotSDN’14, 2014.
  31. ^ D. Tuncer, M. Charalambides, S. Clayman, G. Pavlou, "On the Placement of Management and Control Functionality in Software Defined Networks," proceedings of 2nd IEEE International Workshop on Management of SDN and NFV Systems (ManSDN/NFV), Barcelona, Spain, November 2015.
  32. ^ "OpenFlow: Proactive vs Reactive". 2013-01-15. Retrieved 2014-07-01.
  33. ^ "Reactive, Proactive, Predictive: SDN Models | F5 DevCentral". 2012-10-11. Retrieved 2016-06-30.
  34. ^ Pentikousis, Kostas; Wang, Yan; Hu, Weihua (2013). "Mobileflow: Toward software-defined mobile networks". IEEE Communications Magazine. 51 (7): 44–53. doi:10.1109/MCOM.2013.6553677.
  35. ^ Liyanage, Madhusanka (2015). Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture. UK: John Wiley. pp. 1–438. ISBN 978-1-118-90028-4.
  36. ^ Jose Costa-Requena, Jesús Llorente Santos, Vicent Ferrer Guasch, Kimmo Ahokas, Gopika Premsankar, Sakari Luukkainen, Ijaz Ahmed, Madhusanka Liyanage, Mika Ylianttila, Oscar López Pérez, Mikel Uriarte Itzazelaia, Edgardo Montes de Oca, SDN and NFV Integration in Generalized Mobile Network Architecture , in Proc. of European Conference on Networks and Communications (EUCNC), Paris, France. June 2015.
  37. ^ Madhusanka Liyanage, Mika Ylianttila, Andrei Gurtov, Securing the Control Channel of Software-Defined Mobile Networks , in Proc. of IEEE 15th International Symposium on World of Wireless, Mobile and Multimedia Networks (WoWMoM), Sydney, Australia. June 2014.
  38. ^ Haranas, Mark (8 October 2016). "16 Hot Networking Products Putting The Sizzle In SD-WAN". CRN. Retrieved 1 November 2016.
  39. ^ "SD-WAN: What it is and why you'll use it one day". 2016-02-10. Retrieved 2016-06-27.
  40. ^ Serries, William (12 September 2016). "SD-LAN et SD-WAN : Deux Approches Différentes pour le Software Defined Networking". ZDNet. Retrieved 1 November 2016.
  41. ^ Kerravala, Zeus (13 September 2016). "Aerohive Introduces the Software-defined LAN". Network World. Retrieved 1 November 2016.
  42. ^ Kreutz, Diego; Ramos, Fernando; Verissimo, Paulo (2013). "Towards secure and dependable software-defined networks". Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. pp. 50–60.
  43. ^ Scott-Hayward, Sandra; O'Callaghan, Gemma; Sezer, Sakir (2013). "SDN security: A survey". Future Networks and Services (SDN4FNS), 2013 IEEE SDN for. pp. 1–7.
  44. ^ Benton, Kevin; Camp, L Jean; Small, Chris (2013). "Openflow vulnerability assessment". Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. pp. 151–152.
  45. ^ Abdou, AbdelRahman; van Oorschot, Paul; Wan, Tao (May 2018). "A Framework and Comparative Analysis of Control Plane Security of SDN and Conventional Networks". IEEE Communications Surveys and Tutorials. to appear.
  46. ^ Giotis, K; Argyropoulos, Christos; Androulidakis, Georgios; Kalogeras, Dimitrios; Maglaris, Vasilis (2014). "Combining OpenFlow and sFlow for an effective and scalable anomaly detection and mitigation mechanism on SDN environments". Computer Networks. 62: 122–136. doi:10.1016/j.bjp.2013.10.014.
  47. ^ Braga, Rodrigo; Mota, Edjard; Passito, Alexandre (2010). "Lightweight DDoS flooding attack detection using NOX/OpenFlow". Local Computer Networks (LCN), 2010 IEEE 35th Conference on. pp. 408–415.
  48. ^ Feamster, Nick (2010). "Outsourcing home network security". Proceedings of the 2010 ACM SIGCOMM workshop on Home networks. pp. 37–42.
  49. ^ Jin, Ruofan & Wang, Bing (2013). "Malware detection for mobile devices using software-defined networking". Research and Educational Experiment Workshop (GREE), 2013 Second GENI. 81-88.
  50. ^ Jafarian, Jafar Haadi; Al-Shaer, Ehab; Duan, Qi (2012). "Openflow random host mutation: transparent moving target defense using software defined networking". Proceedings of the first workshop on Hot topics in software defined networks. pp. 127–132.
  51. ^ Kampanakis, Panos; Perros, Harry; Beyene, Tsegereda. SDN-based solutions for Moving Target Defense network protection (PDF). Retrieved 23 July 2014.
  52. ^ a b Sherwood, Rob; Gibb, Glen; Yap, Kok-Kiong; Appenzeller, Guido; Casado, Martin; McKeown, Nick; Parulkar, Guru (2009). "Flowvisor: A network virtualization layer". OpenFlow Switch Consortium, Tech. Rep.
  53. ^ Al-Shaer, Ehab & Al-Haj, Saeed (2010). "FlowChecker: Configuration analysis and verification of federated OpenFlow infrastructures". Proceedings of the 3rd ACM workshop on Assurable and usable security configuration. pp. 37–44.
  54. ^ Canini, Marco; Venzano, Daniele; Peresini, Peter; Kostic, Dejan; Rexford, Jennifer; et al. (2012). A NICE Way to Test OpenFlow Applications. NSDI. pp. 127–140.
  55. ^ Bernardo and Chua (2015). Introduction and Analysis of SDN and NFV Security Architecture (SA-SECA). 29th IEEE AINA 2015. pp. 796–801.
  56. ^ B. Pfaf; et al. (February 28, 2011). "OpenFlow Switch Specification" (PDF). Retrieved July 8, 2017.
  57. ^ T. Zhu; et al. (October 18, 2016). "MCTCP: Congestion-aware and robust multicast TCP in Software-Defined networks". 2016 IEEE/ACM 24th International Symposium on Quality of Service (IWQoS). IEEE. pp. 1–10. doi:10.1109/IWQoS.2016.7590433. ISBN 978-1-5090-2634-0. Retrieved July 3, 2017.
  58. ^ M. Noormohammadpour; et al. (July 10, 2017). "DCCast: Efficient Point to Multipoint Transfers Across Datacenters". USENIX. Retrieved July 3, 2017.
  59. ^ M. Noormohammadpour; et al. (2018). QuickCast: Fast and Efficient Inter-Datacenter Transfers using Forwarding Tree Cohorts. arXiv:1801.00837. doi:10.31219/ Retrieved January 23, 2018.
  60. ^ a b William, Stalling (2016). "Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud". Pearson Education.
  61. ^ Rowayda, A. Sadek (May 2018). "An Agile Internet of Things (IoT) based Software Defined Network (SDN) Architecture". Egyptian Computer Science Journal. 42 (2): 13–29.
  62. ^ Platform to Multivendor Virtual and Physical Infrastructure
  63. ^ Graham, Finnie (December 2012). "The Role Of DPI In An SDN World". White Paper.
  64. ^ Series, Y. (May 2015). "Global Information Infrastructure, Internet Protocol Aspects And NextGeneration Networks". ITU-T Y.2770 Series, Supplement on DPI Use Cases and Application Scenarios.

Seed Phrase

Bitcoin Wiki Entry

Seed phrase

A seed phrase, seed recovery phrase or backup seed phrase is a list of words which store all the information needed to recover a Bitcoin wallet. Wallet software will typically generate a seed phrase and instruct the user to write it down on paper. If the user's computer breaks or their hard drive becomes corrupted, they can download the same wallet software again and use the paper backup to get their bitcoins back.

Anybody else who discovers the phrase can steal the bitcoins, so it must be kept safe like jewels or cash. For example, it must not be typed into any website.

Seed phrases are an excellent way of backing up and storing bitcoins and so they are used by almost all well-regarded wallets.[1]


An example of a seed phrase is:

   witch collapse practice feed shame open despair creek road again ice least

The word order is important.

An example seed phrase written on paper
Example seed phrase on paper.


A simplified explanation of how seed phrases work is that the wallet software has a list of words taken from a dictionary, with each word assigned to a number. The seed phrase can be converted to a number which is used as the seed integer to a deterministic wallet that generates all the key pairs used in the wallet.

The English-language wordlist for the BIP39 standard has 2048 words, so if the phrase contained only 12 random words, the number of possible combinations would be 2048^12 = 2^132 and the phrase would have 132 bits of security. However, some of the data in a BIP39 phrase is not random,[2] so the actual security of a 12-word BIP39 seed phrase is only 128 bits. This is approximately the same strength as all Bitcoin private keys, so most experts consider it to be sufficiently secure.[3]

It is not safe to invent your own seed phrase because humans are bad at generating randomness. The best way is to allow the wallet software to generate a phrase which you write down.

Two-Factor Seed Phrases

Seed phrases, like all backups, can store any amount of bitcoins. It's a concerning idea to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a password.

The password can be used to create a two-factor seed phrase where both "something you have" plus "something you know" is required to unlock the bitcoins.

This works by the wallet creating a seed phrase and asking the user for a password. Then both the seed phrase and extra word are required to recover the wallet. Electrum and some other wallets call the passphrase a "seed extension", "extension word" or "13th/25th word". The BIP39 standard defines a way of passphrase-protecting a seed phrase. A similar scheme is also used in the Electrum standard. If a passphrase is not present, an empty string "" is used instead.

Warning: Forgetting this password will result in the bitcoin wallet and any contained money being lost. Do not overestimate your ability to remember passphrases especially when you may not use it very often.

Warning: The seed phrase password should not be confused with the password used to encrypt the wallet file on disk. This is probably why many wallets call it an extension word instead of a password.

Storing Seed Phrases for the Long Term

Most people write down phrases on paper but they can be stored in many other ways such as memorizing, engraving on metal, writing in the margins of a book, chiseling into a stone tablet or any other creative and inventive way.

For storing on paper writing with pencil is much better than pen[4][5]. Paper should be acid-free or archival paper, and stored in the dark avoiding extremes of heat and moisture[6][7][8].

Some people get the idea to split up their phrases. Storing 6 words in one location and the other 6 words in another location. This is a bad idea and should not be done, because if one set of 6 words is discovered then it becomes easier to bruteforce the rest of the phrase. Storing bitcoins in multiple locations like this should be done via multisignature wallets instead.

Another bad idea is to add random decoy words that are somehow meaningful to you, and later remove them to be left only with the 12 word phrase. The phrase words come from a known dictionary (see next section), so anybody can use that dictionary to weed out the decoy words.

It could be a good idea to write some words of explanation on the same paper as the seed phrase. If storing for the long term you may forget what a phrase is how it should be treated. A sample explanation that can be adapted is:

These twelve words have control over BITCOINS. Keep this paper safe and secret, like cash or jewelry. The bitcoin information on this paper is encrypted with a passphrase. It is part of a multisignature wallet and was made by Electrum bitcoin wallet software on 1/1/2012.

Word Lists

Generally a seed phrase only works with the same wallet software that created it. If storing for a long period of time it's a good idea to write the name of the wallet too.

The BIP39 English word list has each word being uniquely identified by the first four letters, which can be useful when space to write them is scarce.

Alternative name "Mnemonic Phrase"

Seed phrases are sometimes called "mnemonic phrases" especially in older literature. This is a bad name because the word mnemonic implies that the phrase should be memorized. It is less misleading to call them seed phrases.

The power of backups

An especially interesting aspect in the power of paper backups is allowing your money to be two places at once. At the London Inside Bitcoin conference the keynote speaker showed 25 paper backups they were carrying -- all password-protected. With that one can carry $100,000 which can instantly be moved to a phone or transferred yet with total security. If it's stolen then there is no risk because it is backed up elsewhere. That is powerful.[9]

See Also


Single Board Computer

A class of computer popularized by the Raspberry Pi. Commonly abbreviated as SBC. Official Skyminers use an Orange Pi Prime.

Official Skyminer SBC


Untested SBCs