Posted on

New Code Helps Lightning Users Protect Their Bitcoin from File Corruption

Imagine this: Alice is one of the “reckless” users testing a new, risky technology.

She’s excited about the potential for bitcoin’s lightning, a technology that advocates hope will bring bitcoin payments to the masses. So, even though developers tell her it’s risky to do so, she’s running the technology on a little computer called a Raspberry Pi anyway, even using it to buy pizza.

But Alice’s Raspberry Pi is having trouble, so she reboots her node to fix the problem. But when she turns it back on, she finds that a very important file had become corrupted when the computer shut down.

And now, all of Alice’s funds are gone.

This troubling problem with lightning has happened to at least a few users. And it’s one of the reasons using lightning today is considered not exactly safe to use. But thousands of users are ignoring this advice, sending payments across the network to see how the novel technology works in action.

Luckily, the sixth major release of the lightning implementation LND, released just last week, aims to solve this problem by putting into place the change “static backup channels” as coded by Lightning Labs CTO Olaoluwa Osuntokun.

As it stands, the fate of a user’s money hinges on one file.

“What happens if your channel.db file gets corrupted? It’s pretty simple: All the funds in your channels are lost,” an explainer article from earlier this month by developer Patrick Lemke reads.

As Suredbits CEO Chris Stewart, who has also put together research on the topic, put it in conversation with CoinDesk:

“Computers are finicky. Maybe your file system is deleted and you’re like shit, how do I get this money back?”

In practice, Osuntokun noted to CoinDesk that this mostly has happened to lightning enthusiasts using Raspberry Pis, which are little hardware devices that cost roughly $30 and are an easy way to stand up a lightning node at a low entry cost.

Saved by a copy

Losing money in this way is not very common, Stewart notes, but he argues that developers are working on “worse case planning.”

There are three main implementations of lightning so far (including Blockstream’s c-lightning and Acinq’s Eclair) all of which have implemented this sort of a backup scheme in some form or another.

LND’s new technology generates a second copy of the important file, allowing users to save an extra version of their lightning wallet file elsewhere, to minimize the risk of it getting lost or “corrupted,” meaning the data was accidentally altered, like staining a drip of coffee on a white shirt.

This is comparable to backing up all your computer files periodically to ensure they’re safe even if the laptop takes its last steps or gets stolen.

With bitcoin, each transaction is stored in the blockchain, on thousands of nodes across the world. But with lightning, the off-chain transaction data is stored on your computer – and your computer alone. If you lose or “corrupt” the file storing state of the channels, then those funds are lost for good.

Another related scenario: if you accidentally use an old version of the channel.db, which turns out to have the wrong information, then your peer will probably think you’re cheating. Thus, you’ll be penalized, losing money.

That’s why this new backup code is so important. To ensure safety of funds, a user needs to save their channel.db backup file in more than one place at once.

“If you run the latest version of LND your node will automatically create a backup of all the bits of information that you need to rescue your channels in case your channel.db file is lost,” Lemke explains.

“We say safe, as care has been taken to ensure that there are no foot guns in this method of backing up channels, vs doing things like rsync ing or copying the channel.db file periodically. Those methods can be dangerous as one never knows if they have the latest state of a channel or not. Instead, we aim to provide a simple safe instead to allow users to recover the settled funds in their channels in the case of partial or complete data loss,” Osuntokun explains in the “pull request” where he first proposed the change.

That said, Lemke stresses that users running the old lightning code are still at risk.

“If you run an older version of LND your channels are not [safe] and you should be aware that you are at risk of losing your funds if your disk gets corrupted,” he wrote.

Malicious peers

So, now that this code has been pushed through, is the problem solved?

Not exactly. As you can see, it’s still a bit of a process for backing up the files. While the infrastructure LND puts into place automatically generates a backup file for users, the user still has to be technical enough to configure where to put it.

Not to mention, Stewart and Cohen point out one problem with the scheme: it’s not completely trustless. Using this backup scheme, a malicious node could steal a counterparty’s funds.

This feature is “good for the average user who’s willing to trust that their peer is not malicious,” Suredbits software engineer Nadav Cohen told CoinDesk, while Stewart noted that the backup solution should work “99% of the time.”

But Stewart also highlighted how Suredbits has been working a lot with different exchanges that are looking to eventually adopt lightning.

“For exchanges, they absolutely need to a [trustless backup scheme]. They’re dealing with lots of money and don’t want to have the risk of losing a lot of funds,” Stewart said.

Osuntokun has this scenario in mind too, noting that Lightning Labs developers are currently building out a feature that works even when a user is dealing with a malicious peer. In the meantime though, they released static backup channels, since they wanted to push out something that works for the most part.

“This infrastructure will be built out in the near future, but until then we have this scheme which will also be a fall back in the scenario that any higher level mechanisms fail,” Osuntokun explained.

In other words, there’s still building to be done.

“We’re not there yet,” as Stewart puts it, arguing there will be more of a need for this kind of feature in the future once people are using the network for even more money.

“With wumbo, people will start transacting more. We need to be concerned in that case,” he added, referencing a Spongebob Squarepants-inspired technology that will one day allow people to transfer even more money across lightning.

But once developers get this scheme working, Cohen argues that it shouldn’t be hard to put something into place that’s easier for users.

He said:

“Backups are in the early stages and it’s a solvable problem. Once we have something that works and doesn’t require trust, I don’t doubt that we can make them better as far as latency.”

Burning bitcoin image via Shutterstock

Posted on

Privacy Crypto Monero Celebrates Its 5th Birthday

One of the most popular cryptocurrencies for privacy protection, monero, celebrated five years of existence this week.

Launched in April 2014, monero has, since its inception, been entirely crowdfunded. And in tune with this decentralized, grassroots structure, monero is almost entirely developed by volunteers.

“Monero is very committed to its decentralized, grassroots structure meaning we took no premine. We don’t take a percentage of the block rewards. There was no [initial coin offering,]” monero contributor Diego Salazar told CoinDesk. Salazar estimated that “depending on people’s time and availability” there is anywhere from 100 to 200 volunteers working on the monero project.

Additionally, the project itself, according Salazar, isn’t just about building a blockchain protocol. It’s about re-defining and bolstering a global movement centered around digital privacy.

Salazar told CoinDesk:

“We’re not just trying to make global internet money. We’re trying to teach people the importance of things like privacy…It’s a very powerful tool and I think it’s a very necessary tool in our day and age.”

To this, Italian developer and Monero contributor “SerHack” released a free PDF version of the book “Mastering Monero” in commemoration of the coin’s fifth anniversary. Originally published in late 2018, the book was fully funded by the monero community and teaches non-crypto users the importance of “private and censorship-resistant transactions.” The project’s online community further commemorated the anniversary with events and, in one instance, a celebratory puzzle.

While monero is not the only blockchain to boast private on-chain transactions, it is the largest among its kind by market capitalization boasting a $1 billion valuation, according to data from CoinMarketCap.

In that five-year span of time, the project has undertaken a series of significant upgrades in a bid to further improve the project, including those aimed at bolstering fungibility and transaction privacy.

Minimum ringsize

“It’s critically important for the fungibility of monero that we don’t know what source of funds you are receiving,” contributor Justin Ehrenhofer told CoinDesk. “That way you don’t know if you’re accepting funds that were used for any other previous purpose.”

From the start, monero aimed to obfuscate fund sources through what are called “ring signatures.” Through ring signatures, transactions are signed by one member of a group of participants (each of whom has private keys), but with the goal of making it difficult to know who among the group actually contributed a particular digital signature.

As Ehrenhofer explained:

“With monero, for every input that you are spending, you will pull other inputs from the blockchain, other people’s random inputs…and it makes it appear as if all these inputs are spent. It makes it seem mathematically like any one of these [inputs] could have possibly been the [transaction] signers.”

However, at launch, pulling from other random user’s transaction inputs called ring signatures was not mandatory. Cryptocurrency exchanges, public mining pools, and other individuals who didn’t care about preserving transaction privacy could opt to have a “ringsize” of zero.

Monero researchers realized that with a large enough number of users not obfuscating their transaction sources, the privacy of other users risked being compromised.

“If I sent a transaction that revealed what real output was spent by me then that means if anyone else made it seem like they spent my output everyone would know that’s a fake spend because in my transaction I obviously spent it,” Ehrenhofer told CoinDesk.

That’s why on March 22, 2016 monero executed a hard fork to restrict all users to obfuscating their transaction sources through a minimum ringsize of three. This meant that users would need to pull from at least three other random transaction inputs in the network when making their own transaction and thereby collectively take part in strengthening the privacy levels of the entire blockchain.

“One of the big challenges monero needed to overcome in the beginning was making their existing infrastructure better,” Ehrenhofer said. “This meant basically forcing people to use best practice and force these ring signatures to actually have use.”

RingCT

The second most influential change in monero’s history also had to do with ring signatures.

Called Ring “Confidential Transactions” (CT), this upgrade executed through a hard fork on January 5, 2017. It effectively added an additional layer of privacy to ring signatures by obfuscating monero transaction amounts.

The activation of RingCT meant that outside of not being able to identify transactions to a source or an address, Monero now made it virtually impossible to find out the transaction amounts being transferred.

“The outputs were already disconnected from addresses,” Ehrenhofer explained. “[RingCT] took this a step further in saying when these outputs are transacted, we don’t know what value they are in either.”

In fact, when looking up a monero address on a blockchain explorer, the warning message users get back on one of the explorer sites reads:

“Uh-oh, for a moment there it seemed that you were trying to peek into this monero address…It really looks like you were, like, trying to check out this dude’s balance. Well, monero says ‘No’!”

The idea for Ring CT originally came from a bitcoin proposal called “Confidential Transactions” proposed by Blockstream CTO Gregory Maxwell. It was then re-purposed by monero developers to work with ring signatures.

However, Ring CT in improving the privacy of the monero blockchain actually made a substantial trade-off to scalability.

“Transactions before Ring CT were about three kilobytes. They were also about 10 times larger than a bitcoin transaction. Ring CT brought these numbers up to about 13 kilobytes so we multiplied by another four or five x,” Ehrenhofer told CoinDesk.

Bulletproofs

To that point, “bulletproofs” — while not improving privacy directly — is still regarded as a major improvement to the network.

Bulletproofs, according to Ehrenhofer, reduced transaction size and verification time on monero by about 80 percent. From 13 kilobytes to 1.5, monero transaction size has dramatically decreased in size – though at present it still remains larger and more difficult to verify than bitcoin transactions.

The technology, released late 2017, was celebrated as a privacy breakthrough and initially created for use on bitcoin by University College of London’s Jonathan Bootle and Stanford’s Benedikt Bunz. Ultimately, monero became the first major cryptocurrency to go live with the technology through a hard fork on October 18, 2018.

Even so, Ehrenhofer notes that verification times on the network are still “really monero’s biggest limitation at the moment.”

Ehrenhofer told CoinDesk:

“The hardest thing we have to scale in monero is not transaction size. It’s the verification time. We can make monero ring [signatures] enormous today…but the verification time would be almost impossible. Even thought it wouldn’t take up that much room on your computer, it would take you forever to figure out what’s what.”

As such, looking ahead Ehrenhofer hopes that forthcoming improvements to the protocol will find a way to increase ring signature sizes to host anonymity sets of over 1,000 at some point.

From Salazar’s perspective, another forthcoming improvement to monero he sees upcoming in the next few months is an upgrade to the network’s user interface and experience (UI/UX).

“A lot of things are being redesigned from scratch like individual pages, the transaction history page, the send and receive page,” he told CoinDesk.

Balloons image via Shutterstock

Posted on

Ethereum Core Developers Debate Benefits of More Frequent Hard Forks

How often is too often to alter consensus?

A group of ethereum’s veteran open-source developers discussed the subject in a bi-weekly meeting Friday, wherein they aired the possibility that system-wide upgrades, also called hard forks, to the software could be enacted as often as every three months.

Wanting to “check the temperature,” the developer asking the question explained that certain upcoming ethereum improvement proposals (EIPs) such as state rents would require multiple upgrades sequentially spaced out for full effect.

Three months, however, in the eyes of Joseph Delong, senior software engineer at venture capital studio Consensys, is “too quick for a turnaround.”

Team lead at the Ethereum Foundation Péter Szilágyi agreed, explaining:

“As a [software] client developer if you’re only job is to implement hard forks and do them then three months is fine but usually clients require a lot of maintenance. So, if you start doing three month hard forks it will essentially take all the time away from general maintenance and performance improvements.”

Ethereum Foundation security lead Martin Hoste Swende, while agreeing that a hard fork every three months “would be a bad thing,” noted that particular cases with simple changes unanimously agree upon could have shorter run times.

“The idea would not be to schedule a hard fork every three months but see if feature X is finished and there exist test cases and it is implemented in all clients. If so, then we can hard fork pretty soon,” argued Swende during the call.

But encouraging developers to take their plans “one step” at a time, Fredrik Harryson CTO of Parity Technologies noted that even a timeline of six months for a planned ethereum hard fork has never been achieved.

“There’s a couple things we probably need to automate in order to do [shorter hard forks] really well. A lot of the time that goes into the hard fork is not just making the code. It’s everything that goes around,” said Harryson.

In addition to this, Ethereum Foundation advisor Greg Colvin noted that most teams building ethereum software clients do not presently have “the right person” to handle essential jobs for hard fork implementation such as “setting up testnets, running test cases, doing testing” among other responsibilities.

To this, Harryson responded the matter was about not having enough finances to onboard such team members. “For us, it’s money. We don’t have enough money behind it,” quipped Harryson.

Multi-step upgrades

But it’s not only a matter of whether or not there should be more frequent hard forks.

Developers during today’s call also discussed whether there was a need for ambitious, longer-term changes to the present ethereum blockchain in light of an impending move to ethereum 2.0 – a new ethereum network which once fully activated users would migrate over to from the current mainnet.

Suggesting that developers like Alexey Akhunov and ethereum founder Vitalik Buterin have cautioned against “changes that aren’t for the survival of the [present ethereum] chain,” Harryson asked:

“How much do we sway outside of this because [EIP 615] leads into a long chain of improvements that go into several years before we’re seeing massive benefits from it.”

EIP 615 is one of five proposals considered for inclusion in the next ethereum hard fork called Istanbul. It aims to introduce improvements to the very heart of the ethereum codebase known as the Ethereum Virtual Machine (EVM) which is responsible for executing all self-deploying lines of code – also called smart contracts – on the platform.

The EVM is also a key technology that other enterprise blockchain initiatives such as Hyperledger have been reported in the past to build interoperability with.

“The design of the EVM makes low-gas-cost, high-performance execution difficult. We propose to move forward with proposals to resolve these problems by tightening the security guarantees and pushing the performance limits of the EVM,” writes the authors of EIP 615 Colvin, Brooklyn Zelenka, Pawel Bylic and Christina Reitwiessner.

However, as noted by Swende during today’s call, EIP 615 as proposed would require at least two hard forks to fully execute and “a positive speed effect” to actual code computations in the EVM would not be noticeable until the latter hard fork is executed.

“That’s my main concern about this EIP, it’s a lot of work but I don’t think it will lead to a much better EVM. It might be better for the external tools like if you’re doing a reverse analysis of the security properties of a smart contract,” said Swende.

Such tooling Zelenka suggested is essential to ensure continued “forward compatibility” with forthcoming EVM upgrades like eWASM and a smooth onboarding experience for smart contract developers in light of “an undetermined ethereum 2.0 release date.”

“There are other options for smart contract developers out there. We need to keep ethereum 1.x alive and that means continuing to move,” argued Zelenka on today’s call.

Agreeing to continue debate and discussion on the EIP in further weeks, Swende concluded that at present he remains skeptical about “implementing such large changes into the old engine which basically takes a couple of hard forks before it finally settles.”

But agreeing with uncertain sentiment around the future of ethereum 2.0, Harryson, who raised the initial question about ambitious, multi-hard fork upgrades said:

“We shouldn’t adjust our roadmap or thinking based on what ethereum 2.0 may or may not be.”

Fork image via Shutterstock

Posted on

Next Bitcoin Core Release to Finally Let Hardware Wallets Connect to Full Nodes

It’s a moment true bitcoin nerds have been waiting for.

In the coming release of Bitcoin Core, the 18th major version of the cryptocurrency’s most widely used software, the code will finally, natively allow users to connect bitcoin full nodes to hardware wallets.

It sounds technical, but it’s a big step for the security for users. Bitcoin full nodes allow users to verify that transactions actually took place, meanwhile, hardware wallets are considered one of the most secure ways to store bitcoin. Thus, making it easier to join the two together is a big win for users who don’t want full control of their bitcoin – and don’t want to lose it.

Bitcoin Core lead maintainer Wladimir van der Laan, who is in charge of coordinating the coming upgrade, told CoinDesk it’s one of the features he’s been most excited about for quite some time.

Still, the change is part of a much broader effort to make bitcoin full nodes easier to use for people other than just tech geeks. Casa, for example, has launched a node that works without much setup necessary, while developers of the bitcoin protocol are constantly trying to reduce how much data users need to store to run one (as users need to store every transaction ever sent on the blockchain, it’s pretty weighty).

As Bitcoin Core contributor Andrew Chow, one of the lead developers on the project, put it on Twitter:

“With this [pull request] merged, the upcoming Bitcoin Core 0.18 release will be finally usable with hardware wallets by using [Hardware Wallet Interface (HWI)].”

He admits it’s “still command line only and manual,” but argued “it’s a big step forward” because the functionality is finally there, even if in a somewhat clunky form. Developers will continue to make it easier to use down the line.

Eating your cake

So first off, why use a bitcoin full node in the first place?

In order to send a transaction on the bitcoin network, users need to connect to a bitcoin node. Full nodes now require a couple of hundred gigabytes of data, which is a lot, enough to fill a small laptop.

But it does serve a purpose, as rather than trust that someone else is feeding you the correct financial information, such as whether you really received a transaction or not, you’re able to validate this information yourself.

As the value proposition of bitcoin is to not trust others, some developers go as far as to argue that using bitcoin in a way that removes the full node defeats the purpose of bitcoin.

Bitcoin Core contributor Sjors Provoost, for example, has argued that running a full node is helpful for “knowing your bitcoin is real,” offering the example of Segwit2x, a proposed bitcoin fork from 2017 in which some companies, miners, and users proposed upgrading bitcoin to a larger block size.

There was concern that in the case Segwit2x broke bitcoin into two, mobile wallets relying on Simplified Payment Verification (SPV) technology would be susceptible to trickery from miners.

“That server can in theory also lie about your balance. In a scenario like SegWit2x, it could decide which side of the fork it wants to show you. With a full node you don’t have to worry about that,” Provoost told CoinDesk.

Then there’s the issue of privacy.

“The wallet software that normally comes with hardware wallets reveals your addresses to a third-party server,” Provoost continued. The full node would replace this wallet software, giving users privacy again.

“At the end of the day, it comes down to the trade-off between convenience and trust,” Bitcoin Core wallet maintainer Samuel Dobson told CoinDesk.

These problems are what’s fueling the idea that maybe one day “everyone” should run this full node software, so they don’t have to trust anyone else to send them accurate financial information.

“Yes, I believe that everybody will eventually run a full node. I wish a future where not having a full node will severely limit your user experience and the realm of things you can do with bitcoin,” as BTCPay creator Nicolas Dorier wrote in a recent blog post.

Secure, offline bitcoin

The other piece is hardware wallets are considered the most secure way to store bitcoin. That’s especially true when compared to storing them on internet-connected computers, which are often totally exposed to hackers.

“PCs are a much larger attack surface than a small dedicated device to store your keys, designed specifically with security in mind. They’re also less prone to random crashes or corruption which could cause you to lose un-backed-up keys on your computer,” Dobson told CoinDesk.

With this new tech in place in the Bitcoin Core software, users can store their bitcoin on an offline hardware wallet, then use their full node to verify the data they’re getting fed, such as transaction data, is correct.

The technology has been a long-time coming. Connecting hardware to a full node is also one of the key goals of Electrum Personal Server, pioneered by developer Chris Belcher. “Hopefully this software can be part of the plan to get full node wallets into the hands of as many people as possible,” he said in the project announcement post last year.

There are pros and cons to each project, though, Provoost admitted.

“The HWI project should reduce the number of separate software components needed, though at the moment I think it’s still less user-friendly [than Electrum Personal Server],” he said.

And there’s still a ways to go to get the graphical interface totally working. “Maybe one day in the future we’ll have this graphical picture that I showed you – and after that we’ll have unicorns,” Provoost said in his presentation on the topic.

Further features

While hardware wallet support in 0.18 has generated much excitement, As usual, the release is filled with other contributions from the pool of global Bitcoin Core contributors.

Dobson told CoinDesk about a few features he finds “exciting,” including refinements to a new “language” that the groundwork was laid for in an earlier version of Bitcoin Core. New commands will allow developers to use this language to “import descriptors.”

“You can provide such a descriptor to Core […] and it will parse it and import the keys, scripts, etc. into your wallet for you,” Dobson said, explaining further:

“This is the first step in a longer term goal to rework the wallet and support these descriptors natively within it, which will clean things up immensely and provide a much more natural behaviours, in line with how you would expect things to behave (and which don’t exactly behave that way currently).”

Dobson also pointed to a new “multiwallet” command, which will allow users to pair with multiple wallets within their bitcoin core full node. While the ability to use multiple wallets at once has existed in the code previously, 0.18.0 plugs the feature in the graphical user interface for the first time, so people no longer have to be full-blown developers using the command line to take advantage of the feature.

“Version 0.18 adds support to the GUI to do that, as well as a few improvements in how it works too,” Dobson said.

As of now, version 0.18 is in the “release candidate” stage of the software development cycle, meaning passionate bitcoin developers and companies are still testing it, picking away at the code in an effort to eradicate any bugs, before it’s released to the larger public to download.

According to project developers, it will be available for users to download in the coming weeks.

Bitcoin image via Shutterstock

Posted on

The Easiest Way to Send and Lose Bitcoin in 2012

Dan Gallancy tells the story of the Bitcoin that he sent to friends, but never quite got there.

Subscribe to CoinDesk on YouTube: http://www.youtube.com/subscription_c…

Site: https://www.coindesk.com
Facebook: https://www.facebook.com/CoinDesk
Twitter: https://www.twitter.com/coindesk
Instagram: https://www.Instagram.com/coindesk
Newsletter: https://www.coindesk.com/newsletter/
Twitter (Markets): https://www.twitter.com/coindeskmarkets

CoinDesk is the leading digital media, events and information services company for the crypto asset and blockchain technology community.