Idelto

Cryptocurrency news website

technical

Plugging into C-Lightning: The Future of Lightning Plugins Is Bright

by

Trying to navigate the different Lightning implementations can be a challenge. Although there were initially three implementations: c-lightning, eclair and lnd, more continue to come out of the woodwork all the time with ptarmigan, rust-lightning and Electrum the most recent to enter the fray.

Often, it seems developers and aspiring developers choose to use or contribute to a particular implementation based on the language it is written in. Familiar with Scala? Choose eclair. Excited by the potential of Rust? Choose rust-lightning. However, there are other key considerations such as the aims, design philosophies, use cases and trade offs of the different implementations. In addition, just because an implementation is written in a certain language doesn’t necessarily mean that you are required to code in that language to contribute to the ecosystem around that implementation.

The emerging contrasts between the lnd and rust-lightning implementations were explored on a panel at Breaking Bitcoin 2019 and in this Bitcoin Magazine article. Whilst lnd seeks to take the load off developers and provide ultimate functionality out of the box, rust-lightning seeks to offer ultimate flexibility with developers encouraged to bring their own components and slot them in. 

In contrast, c-lightning offers a third way. It maintains a robust and secure core that is designed to not be tweaked or replaced by the developer. Flexibility and additional functionality is available through the use of plugins that can be written by the developer in various languages such as Python or Go. The aim is for the c-lightning ecosystem to emerge as a testbed for experimenting with new cutting edge features, previously the terrain of other implementations such as lnd and eclair, without sacrificing the performance and robustness of the core.

Plugins are subprocesses that are started by the main lightningd daemon. They work in cooperation with lightningd. Any plugins that are surplus to requirements do not need to be run. Some plugins do need certain hooks to be introduced into lightningd that will notify the plugins about internal events and/or alter the behavior of lightningd.

The First C-Lightning Plugins

Blockstream has a series of Medium blog posts to showcase some of the first plugins written by the c-lightning team. These include the “Summary” plugin which provides a summary of node status including satoshis onchain, what that amounts to in fiat terms, number of peers, number of channels, how balanced are they, etc. 

The “Probe” plugin determines whether there is a route to make a payment to a certain node in the network, returns the fee level required and indicates which channel(s) are preventing a successful payment. This can be used to prepare the groundwork for a future payment or merely to explore the topology of the network. 

The “Prometheus” plugin collects data on the performance of your node to provide visualizations and alerts. With all of these plugins you could choose to contribute to the plugin by adding a feature or building your own from scratch.

Community Plugins

In total there are 16 “community curated” plugins for c-lightning available at the time of writing. These include an autopilot plugin ported from a library built by Rene Pickhardt. Autopilots decide which nodes to open channels with on behalf of the user. The user needs to tell the autopilot the percentage of funds under their control, the number of channels to be opened and the minimum channel size. The autopilot also needs to be notified by lightningd when channels are opened and closed by remote parties. Building an effective autopilot is challenging as user preferences, such as maximizing the probability of a successful payment, can conflict with network health, such as the level of decentralization. 

There is also a rebalance plugin, which moves liquidity between the user’s channels to ensure there is sufficient incoming and outgoing liquidity; and an invoiceless payment plugin, which allows a user to make a payment without first receiving an invoice. When running c-lightning you can choose to turn on or off any combination of these plugins.

As Lisa Neigut (@niftynei) said in her tweetstorm, c-lightning doesn’t provide “a standardized HTTP accessible interface out of the box nor an authentication scheme” for third-party app developers like lnd does. But community-built plugins offer the opportunity to build equivalents for c-lightning that exist in other implementations. 

Kristaps Kaupe has started a GitHub repo for plugins emulating some lnd commands. Other plugin authors worth highlighting are Richard Bondi, who has written a collection of plugins in Go, including a plugin to ban peers; fiatjaf, who has written a plugin implementing LN URL to help the payer interact with the payee; and Conor Scott, who has written a number of plugins in Python including a plugin to create channels with top capacity nodes. Finally, Justin Moon has built a proof-of-concept plugin to fund Lightning channels with hardware wallets.

The Challenges of Plugins

Although this plugin architecture seems to offer the best of both worlds, it does present some challenges and potential downsides. It is not clear at this stage whether the ultimate flexibility of rust-lightning will mean it is better suited for existing Bitcoin wallets seeking to integrate Lightning into their existing codebase.

In addition, as the number of community plugins multiply and the value of Bitcoin relying on these plugins increases, security and curation are going to be critical. There will inevitably be duplication and overlap between plugins. 

Curation is challenging because it effectively recommends (unofficially, caveat emptor) which plugins should be used and which shouldn’t. Without curation, it becomes impossible for users and developers to get started quickly without examining all of the competing plugins. There is an argument that some languages (and some developers!) are better suited to writing security-critical software. However, the particularly dangerous JSON-RPC methods can only be installed with the developer option and are only intended for testing and debugging with the assistance of the c-lightning team. There is also guidance available on the dangers a plugin developer might incur when taking advantage of a particular hook that can change the default behavior of c-lightning.

It is not the case that this approach creates a perfectly permissionless environment for developers, as some future plugins will still require additional hooks to be merged into the c-lightning codebase by the c-lightning team. For example, a hook to facilitate a watchtower plugin is in discussion at the time of writing. It is possible that some hooks won’t be merged due to security concerns or implementation details.

It remains to be seen whether instances of c-lightning nodes running different sets of plugins cause compatibility issues between c-lightning nodes or with other implementations. It is already challenging to ensure compatibility between different implementations, assuming c-lightning nodes are all running the same release. Experimentation is important, though, and lessons from this experimentation will prove invaluable when finalizing the BOLT specifications for the Lightning protocol.

London Bitcoin Devs

The opportunity to build and play around with new plugins in a wide selection of different languages is drawing developers into building on top of c-lightning. Antoine Poinsot (@darosior) came to London to present at the London Bitcoin Devs meetup in March 2020. Poinsot is developing a plugin manager called Reckless which will offer a selection of plugins to the user and start the chosen plugins dynamically. He has also built an RPC command hook which allows a plugin to take over any RPC command and change it. This is potentially reckless and experimental as RPC commands are how users interact with lightningd. If RPC commands can be accepted, rejected or changed it opens up a number of use cases but also possibilities for users to lose their funds.

This RPC command hook formed the basis of Rusty Russell’s most recent presentation at the online Boltathon 2. There is still a whole swathe of plugins that could be built from trampoline routing to HODL invoices, and Christian Decker expects “There’s already a plugin that does that” to become a meme. In that case, Decker and the c-lightning community may just have their work cut out curating this emerging jungle of plugins.

Thanks to Antoine Poinsot and Christian Decker for their contributions to this article.

The post Plugging into C-Lightning: The Future of Lightning Plugins Is Bright appeared first on Bitcoin Magazine.

The King of Blockchains, Bitcoin Can Become the Foundation for Web 3.0

by

Bitcoin remains the undisputed “king” of blockchains. Bitcoin’s dominance has increased significantly since the experimental times of 2017. Bitcoin has survived many attempted forks and “civil wars” and has established itself as the reserve cryptocurrency; people fall back to Bitcoin in bear markets. The production network has stood the test of time for over 10 years now. 

However, the crypto industry has dismissed Bitcoin when it comes to smart contracts or Web 3.0. I believe this is going to change.

It’s true that Bitcoin cannot do everything. Bitcoin is secure because it has a limited scripting language. Bitcoin is reliable and durable because it doesn’t change. This does not mean that the developer ecosystem around Bitcoin cannot innovate and enable support for Web 3.0. As the crypto industry makes progress toward Web 3.0, we’ll come to realize that it’s hard to beat the security and network effects of Bitcoin.

Despite several initiatives by potential competitors, the hashrate of the Bitcoin network and the security offered by its proof-of-work (PoW) mining remain unparalleled to this day. For years, new cryptocurrencies have attempted to launch their own native PoW networks; none has approached Bitcoin’s success.

Bitcoin has network effects. Most people are introduced to cryptocurrencies through Bitcoin. If something can be done on top of Bitcoin, it will eventually get done on top of Bitcoin rather than a smaller ecosystem. Network effects make Bitcoin’s success self-reinforcing: Miners see that the network is established, that the community is strong and that the currency is the “hardest” money in the crypto space. Miners join or expand their commitment, increasing hashpower and network reliability; their entry inspires still more holders and businesses, increasing community support. The cycle goes on.

Smart Contracts on Bitcoin

Despite the success of Bitcoin, critics who question Bitcoin’s capacity for innovation have some valid points. There are aspects of Bitcoin that frustrate developers who wish to explore the world of smart contracts and decentralized apps. Many projects have created their own blockchains because they perceive Bitcoin’s scripting limitations as a dealbreaker. They cannot deny the original chain’s security, but they also wish they could write more expressive smart contracts. New blockchains find themselves struggling with poor, native PoW security, and often attempt jumps to proof of stake (PoS) or delegated PoS setups which may be less secure and tend toward centralization.

As a result, several crypto projects have concluded that they must pick their poison: They must either attempt to bootstrap a native PoW chain or else establish a PoS chain, with all of the tradeoffs that entails. 

But these are not the only options. There is a different path available: Smart contract platforms can employ Bitcoin’s PoW security to safeguard new blockchains. 

New protocols can anchor to the security of Bitcoin and extend Bitcoin’s utility. Transactions that settle on Bitcoin are harder to reorganize than they are on any other network. This is an under-explored design space but one which is beginning to change. 

The Bitcoin blockchain already has security derived from its energy expenditure and this security may be passed on to the interconnected chain by using concepts like proof-of-transfer (PoX). It’s important to recognize that interconnected chains differ from traditional sidechains; interconnected chains create their own crypto assets, but they utilize the Bitcoin chain for broadcasting mining operations and consensus steps. An interconnected chain anchored to Bitcoin is a win-win proposition for all parties as the new blockchain benefits from the reliability, and longevity of Bitcoin while providing freedom and flexibility to developers working with the interconnected chain.

The Bitcoin blockchain can also reap benefits, acquiring new and powerful use cases. These can attract new miners and new network participants, further solidifying Bitcoin’s place as the reserve cryptocurrency.

Smart contract platforms, and I include my own project, Blockstack, in this, understand how powerful on-chain contracts can be. But just as you don’t need to build all new roads to drive new cars, there’s no need to reinvent PoW or PoS chains to employ robust smart contracts or to launch new blockchains. The solid foundation we need to realize our vision for Web 3.0 is already here; a future Web 3.0 can anchor on Bitcoin.

Image credit: William Krause on Unsplash

This is an op ed contribution by Muneeb Ali. Views expressed are his own and do not necessarily reflect those of Bitcoin Magazine or BTC Inc.

The post The King of Blockchains, Bitcoin Can Become the Foundation for Web 3.0 appeared first on Bitcoin Magazine.

How Bitcoin Optech Is Connecting the Open-Source and Corporate Worlds

by

Bitcoin Core and other open-source projects have, over the years, built a range of technologies to improve Bitcoin scaling and the general Bitcoin user experience. With examples including Segregated Witness (SegWit), Replace-By-Fee and the Lightning Network, Bitcoin users have a number of tools at their disposal to utilize the Bitcoin blockchain as best and efficiently as possible.

Yet, bigger companies in particular have historically been slow to adopt such tools. Segregated Witness is a prime example: Several of the largest Bitcoin businesses hadn’t adopted the upgrade for over a year after it was activated on the Bitcoin network in August 2017. The total share of SegWit transactions even remained below 50 percent until the second half of 2019.

This was also noticed by John Newbery, engineer at Chaincode Labs; Steve Lee, former Google product director turned product manager at Square Crypto; and James O’Beirne, former Chaincode engineer who recently joined DG Lab. Seeing this and other discrepancies, they wanted to help resolve the apparent disconnect. In mid-2018, the trio founded an initiative to bridge the gap: Bitcoin Optech.

“Bitcoin is the most mature blockchain, and even though it’s been around the longest, there’s still a lot of inefficiencies with the usage of the blockchain, and it is a scarce resource,” Lee explained, as he announced the project at the Distributed 2018 conference in July 2018. “That’s really what we’re focused on, helping various actors in the ecosystem to figure out how to best do that.”

The initiative would consist of several projects united under the Bitcoin Optech umbrella.

The first of these projects is a series of workshops, bringing open-source developers and engineers at Bitcoin companies together to discuss relevant technologies in person. These workshops offer technical knowledge to all the participants, while also bringing together different parts of the Bitcoin ecosystem to hopefully help further cooperation — parts that sometimes have different perspectives on the industry, with open-source developers and Bitcoin companies occasionally finding themselves in conflict with one another.

“Bringing people together and having face-to-face meetings is really beneficial, it helps foster a more collaborative ecosystem,” Newbery explained during the same Distributed 2018 announcement. “On a purely technical level, having that experience feedback from engineers actually doing work on the ground, back to the open-source community makes those open-source projects better, and having information going from the open-source community into these companies lets those companies use better technology.”

The first Bitcoin Optech workshop took place in San Francisco in July 2018. Fourteen engineers from Square, Coinbase, BitGo, Purse, Xapo and Ledger discussed topics including coin selection, fee estimation and Replace-By-Fee, as well more general topics like establishment of the Bitcoin Optech initiative itself and communication between the different parts of the Bitcoin ecosystem.

The initiative has grown significantly since then. A second workshop was organized in Paris (November 2018), followed by another event in San Francisco and one in New York (both in September 2019). The fifth and most recent workshop took place in London on February 5, 2020. Bitcoin Optech today counts 24 member companies who support the initiative financially, including the likes of Bitstamp, Kraken, Casa, OKcoin, Bitrefill and others. The vast majority of member companies also participated in at least one of the workshops. 

The Bitcoin Optech team itself has grown as well. Although O’Beirne stopped contributing after 2018, Blockstream’s product manager Mike Schmidt, Chaincode Labs associate Adam Jonas and Chaincode Labs engineer Carl Dong have been taking on various organizational roles within the initiative.

“I think Bitcoin Optech has grown to be a trusted voice on technical Bitcoin matters and continues to highlight ways in which users and businesses can make more efficient use of the blockchain,” Newbery told Bitcoin Magazine, reflecting on the 20 months since the initiative got off the ground.

The Bitcoin Optech newsletter is the second big project under the Bitcoin Optech umbrella. Produced by technical writer David Harding and counting 84 editions at the time of writing, the newsletter continues to accumulate a wealth of information, containing high-quality technical documentation and offering an ongoing overview of developments across Bitcoin and Lightning implementations.

Among the more notable efforts carried out through the newsletter, Harding wrote a 24(!)-part series on bech32 sending support, encouraging wallet providers and companies to implement the option to send funds to bech32 addresses, the address format introduced in Bitcoin Core 0.16.0. With bech32, users can fully utilize the extra blockspace offered by SegWit and enjoy a number of other benefits. Nineteen of the 23 popular wallets integrated this option, while four of them even generated bech32 receiving addresses by default — though it is, of course, hard to say how much of this was due to the series specifically. 

Other projects under the Bitcoin Optech umbrella include a dashboard with detailed statistics and adoption metrics on a range of technologies; compatibility matrices with overviews of SegWit and Replace-By-Fee support across different wallets; and the Scaling Cookbook, a technical document for scaling technologies for engineers and businesses. Bitcoin Optech also offers a broad overview on Bitcoin-related technical topics, which has grown to become a go-to resource for many. 

Perhaps at least as important, Bitcoin Optech has probably helped heal a rift caused by the years-long scaling dispute. Having started with nothing but an idea midway through 2018, and helped by seed money from Xapo founder Wences Casares, venture capitalist John Pfeffer and Chaincode Labs co-founder Alex Morcos, Bitcoin Optech’s focus on technical solutions may well have been instrumental in aligning different parts of the Bitcoin ecosystem.

“I think it is going very well and exceeding our expectations in terms of company engagement and impact the workshop content and newsletter has,” Lee told Bitcoin Magazine. “It is hard to say how much actual adoption of various optimizations is due to Optech, but at minimum I think Optech has helped the post-SegWit2X healing process, and given businesses better insight into how the open source developers and process work.”

The post How Bitcoin Optech Is Connecting the Open-Source and Corporate Worlds appeared first on Bitcoin Magazine.

Infographic: Who Has Funded Bitcoin Core Development?

by

Monetarily, free and open-source software (FOSS) has always been at a disadvantage to proprietary software. It’s easier to solicit funding for a centralized project than for a decentralized one, not least of all because companies necessitate business models.

Conversely, funding (and the agendas that often come with it) seems almost anathema to FOSS projects. At the very least, it is elusive. And Bitcoin is no exception.

When creating Bitcoin, Satoshi asked for no compensation of any kind (it was, after all, still an open-source project). Satoshi also never tapped the trove of bitcoin he had horded as a result of his mining activity on the network. By some combination of need for funding, following Satoshi’s example and sheer passion for the project, Bitcoin developers would continue to work on the code without promise of pay for years.

This would change in 2012 with the creation of the Bitcoin Foundation, a nonprofit which pooled capital to fund Bitcoin Development. Nonprofit as it was, the Bitcoin Foundation played a similar role as Red Hat, Inc., a corporation dedicated to FOSS development, or Microsoft, which still helps with maintaining and developing the Linux OS source code.

The Bitcoin Foundation has since shut down, but other initiatives have stepped into its place, such as the MIT Digital Currency Initiative (MIT DCI) and Chaincode Labs. And other Red Hat-like companies, such as Blockstream, would also emerge to maintain and advance the Bitcoin Core software.

Below is a flow chart indicating which organizations have supported some of the most prevalent Bitcoin Core contributors over the years. Please note that this list is not exhaustive and does not include anonymous donations or other private funding efforts to independent developers.

This infographic indicates which organizations have supported some of the most prolific open-source Bitcoin Core contributors over the years.

The post Infographic: Who Has Funded Bitcoin Core Development? appeared first on Bitcoin Magazine.

Paying Yourself? Self-Payments Could Be a Key to Lightning Privacy

by

The Lightning Network is best known for its fast and cheap payments. But the Layer 2 protocol could also offer more privacy than on-chain payments, since transactions are not published on Bitcoin’s blockchain, blockchain analysis is largely impossible.

The Lightning Network does present its own privacy risks, however. Payments are routed over a network of users, and nothing stops spies from participating in this process of forwarding transactions while monitoring the flow of funds. On the Lightning Network, blockchain analysis can be substituted for network analysis.

There are some solutions to limit these risks, like Tor-style onion routing. These help, but, depending on network topology and types of payments, weaknesses can remain. The Bitcoin and Lightning developer going by the pseudonym ZmnSCPxj has, in recent weeks, published extensive analysis of persisting risks on the Lightning-dev mailing list (1, 2, 3).

Based on his analysis, ZmnSCPxj also offered a solution. Similar to Payswap — his proposal for on-chain privacy, covered by Bitcoin Magazine two weeks ago — the developer thinks that “self-payments” could be an important part of the privacy puzzle.

Understanding Self-Payment

In a previous article, we discussed Payswap, a proposal by ZmnSCPxj to improve on-chain privacy by seemingly inverting the relation between payer and payee. ZmnSCPxj actually initially came up with this idea in the context of the Lightning Network. In fact, it would probably be of even better use on the Lightning Network: Some of the trade-offs embedded in the on-chain alternative do not apply on the Layer 2 protocol.

In short, for the Lightning version of Payswap, the self-payment is part of the same payment route.

To explain how this works, let’s look at an extremely simplified version of a Lightning Network. A(lice) has payment channels with B(ob) and C(arol). Bob has channels with Alice and D(ave). Carol has channels with Alice and Dave. And Dave has channels with Bob and Carol.

A — — B

 |            |

 |            |

C — — D

If Alice wants to pay Dave 3 bitcoin, she’d normally route the payment through either Bob or Carol. Bob or Carol would charge a small fee for the service, but for simplicity, we’re going to ignore fees in this example. However, the fact that, in reality, fees are paid will be relevant a few paragraphs down, so keep that in mind. 

For now, we’ll say that Alice opts for Bob’s route to make the payment. She sends 3 coins to Bob, and Bob goes on to forward 3 coins to Dave. The payment is a success.

But unfortunately, in this example, it would be easy for Bob to correctly assume that Alice paid Dave 3 coins. He knows the amount because he forwarded it, while if Alice wanted to pay Carol, or Carol wanted to pay Dave, they could have done so directly, without depending on Bob as an intermediary. If Bob is a spy monitoring network traffic, his correct assumption harms both Alice and Dave’s privacy.

ZmnSCPxj, therefore, proposes an alternative. Alice could route the payment all the way back to herself … a “self-payment,” with Dave taking a very big “fee.” The fee would in actuality be the real payment.

To pay Dave like before, Alice would, for example, route 5 coins this time. First, she’d send the 5 coins to Bob, who would forward the 5 coins to Dave. Then — this is the trick — Dave would go on to forward the payment, to Carol … but he only forwards 2 coins! Lastly, Carol would forward the 2 coins back to Alice. In the end, Alice is 3 coins poorer, and Dave is 3 coins richer. Hence, Alice paid Dave 3 coins.

This self-payment would mislead both Bob and Carol. Bob forwarded 5 coins and may logically but wrongly assume that Alice paid Dave 5 coins. Meanwhile, Carol would arguably be even worse off: She’d think that Dave paid Alice 2 coins. From Carol’s perspective, the direction of the payment is inverted.

If either Bob or Carol were secretly spying on network activity, they would have been misled about the size and/or direction of the payment, benefiting Alice and Dave’s privacy. If spies are misled often enough, it could even render such spying activity useless altogether.

PTLCs, Standard Amounts and More

Everything about the example above is simplified, from the network graph to the amounts transacted, while more subtle privacy risks such as fee amounts and timelocks are ignored altogether. Meanwhile, it is assumed that even if both Bob and Carol are spies, they are not cooperating, or worse: They are one spy pretending to be two users.

In reality, both the privacy risks and privacy benefits of routing are greater and more nuanced at the same time. Addressing all these subtleties is beyond the scope of this article; ZmnSCPxj’s submissions to the Lightning-dev mailing list are a better resource for a more in-depth analysis. And more generally, research into Lightning privacy is ongoing.

Still, it’s worth pointing out that ZmnSCPxj’s proposals to improve Lightning privacy go beyond self-payments — in some scenarios, additional protocol changes would in fact be more-or-less necessary for self-payments to be effective privacy improvements. The two most important changes are a switch from hashed timelock contracts (HTLCs) to public key timelock contracts (PTLCs), and adoption of standard amounts. So let’s look at these two in brief.

Right now, Lightning payments are routed using HTLCs. All users along a route essentially pass on a code which guarantees that they can claim funds from one counterparty if the other counterparty claims funds from them (This is how funds are forwarded over the network). Unfortunately, if cooperating spies are part of the same route, they can use the HTLCs to tell that different hops are in fact part of the same payment, to an extent undoing the benefit of onion routing. PTLCs would leverage cryptographic tricks to prevent spies from linking different hops to the same route.

ZmnSCPxj also proposes that Lightning users adopt standard amounts. While optional, wallets would be encouraged to split payments up into smaller (but interlinked) payments, where each smaller payment consists of standard amounts. If the standard amounts are for example 1, 2 and 5 coins, Alice in the above example would make two payments of 1 coin and 2 coins, instead of one payment of 3 (Or, if she makes a self-payment, she could send 5 and route 2 back to herself).

If enough users would limit their (fractions of) payments to standard amounts, spies cannot rely on amounts to link different hops to the same payment. In the context of self-payments, users could even route nonstandard amounts from the payee back to themselves, making these look even more like regular payments.

Self-Payment Drawbacks

The on-chain version of ZmnSCPxj’s proposal, Payswap, comes with significant trade-offs. Compared to a regular payment, more transactions are needed, which translates into higher fees. On top of that, Payswap transactions require interaction between users outside of the Bitcoin protocol; regular bitcoin transactions do not.

On the Lightning Network, these drawbacks don’t hold up — or they hold up to a lesser extent. Lightning payments require interaction in either case, so a self-payment wouldn’t make the situation worse. And while some extra transaction hops are necessary to make a self-payment, these hops happen off-chain, so they don’t require extra blockspace.

That said, self-payments still come with some drawbacks, even on Lightning. While cheaper than on-chain fees, extra hops do cost a bit more in routing fees. Additionally, as more hops are added to a payment, the risk of a failed payment increases, and the risk of a spy being part of a route increases, too (If only Carol was a spy in the example above, the self-payment would have given her more information than a simple route through Bob would have).

Lastly, of course, there might be other (as of yet unforeseen) trade-offs as well; self-payments are a relatively new proposal. As ZmnSCPxj concluded in his emails, “More analysis on the use of circular payments when paying may be in order.”

The post Paying Yourself? Self-Payments Could Be a Key to Lightning Privacy appeared first on Bitcoin Magazine.