The post Keep an Eye Out for These Bitcoin Tech Trends in 2018 appeared first on Bitcoin Magazine.
The post Keep an Eye Out for These Bitcoin Tech Trends in 2018 appeared first on Bitcoin Magazine.
“Forkcoins,” or “Initial Fork Offerings” — alternative coins that “split off” from Bitcoin — are all the rage right now.
The latest trend in the cryptocurrency world was kicked off last summer with the launch of Bitcoin Cash. The Bitcoin offshoot is a top 3 cryptocurrency by market cap according to websites like Coinmarketcap. Perhaps even more importantly, it is now offered by some of the world’s biggest Bitcoin exchanges and wallet providers, including Coinbase, Bitstamp and Blockchain. The second Bitcoin offshoot, Bitcoin Gold, also claimed a top 10 cryptocurrency spot seemingly out of nothing. Perhaps unsurprisingly, therefore, a series of new forkcoins has been announced over the past couple of weeks, ranging from Bitcoin Diamond to Lightning Bitcoin to United Bitcoin and many more.
Since this week, anyone can easily create their own forkcoin with the click of a few buttons. Forkgen lets users tweak Bitcoin’s parameters and other properties to fork into a unique Bitcoin offshoot by simply filling them in on a user-friendly website.
The service is created by a pseudonymous developer who simply goes by the name “One,” who is assisted by “Two,” Forkgen’s “social media intern.”
Two told Bitcoin Magazine that the service intends to democratize the creation of Bitcoin forks.
“Even leading developers have shown it is too hard to create forks of the Bitcoin blockchain without making critical errors,” Two said, referring to the recent failed SegWit2x launch. “Forkgen creates a level playing field where anyone can easily create working forks. Then it reduces to a much simpler problem of marketing your new altcoin. More people are good at that part.”
To test the service, Bitcoin Magazine decided to create our own Initial Fork Offering.
Right now, Forkgen lets users pick a name and three-letter-ticker for their forkcoin, as well as a block weight limit and a block height for the fork to take place. Additionally, Forkgen users can choose whether they want to implement replay protection to ensure no one accidentally loses their forkcoin. Further, they can opt for a mining difficulty reset to make new coins easier to mine at first. Forkgen users can also pick the letters and numbers to start the coin addresses and private keys with — and they can decide how much they want to tilt the Bitcoin logo to distinguish it from the original, like Bitcoin Cash did.
Given these tools, we designed our forkcoin: “Bitcoin Magazine Cash,” with the ticker “BMG.” We opted for strong replay protection and a difficulty reset, to make the coin as usable as possible. The Bitcoin Magazine Cash protocol will have a block weight limit of 20120501, an ode to Bitcoin Magazine’s launch date (May 2012), which is also five times bigger than Bitcoin’s limit. Addresses will start with a B or an M, and private keys with an i. Finally, the logo will be tilted 45 degrees counterclockwise, for no particular reason.
Bitcoin Magazine Cash forked away from Bitcoin at block 500400: a couple of hours before publication of this article. Anyone who held Bitcoin private keys at 12 PM UTC on December 21, 2017, has now been awarded their free BMG. It should be possible to claim these coins with the Bitcoin Magazine Cash software and your Bitcoin private keys — though we don’t actually recommend this (for reasons explained below).
As of yet, it unclear whether any exchanges will support the fork, but Two suggests that all of them really must:
“Exchanges should be obligated to split and distribute all arbitrary fork coins despite the systems expense and security risk. Who are they to decide what makes one fork more legitimate than any other?”
Although the service should work, on its website Forkgen describes itself as “interactive performance art.”
A play on Coingen, a now-defunct altcoin generator, Forkgen emphasizes how easy it is to create Bitcoin forks, that — like the thousands of altcoins out there — in the end are of questionable relevance. Where Coingen was created during the first big altcoin boom of 2013 and 2014 that birthed Bitcoin codebase forks such as Dogecoin, Vertcoin and Viacoin, the recent trend of forkcoins is really the same thing, the Forkgen project seems to suggest.
Two ardently denied Forkgen is something akin to joke.
“This is VERY SERIOUS. Read the FAQ,” he said. “Forkgen is the embodiment of Satoshi’s True Vision™ where if big blocks are good for scaling then many chains are even better.”
Binaries for Bitcoin Magazine Cash (BMG) can be downloaded here for Windows, Mac and Linux. However, Bitcoin Magazine cannot in any way guarantee the authenticity of these binaries that were provided by Forkgen — nor does Forkgen. Download and run the software at your own risk; and keep in mind that exposing private keys that hold value to untrusted software is a particularly bad idea.
Additionally, keep in mind that Bitcoin Magazine merely created this software as an experiment; we have no intention of actually maintaining it, nor will we support Bitcoin Magazine Cash in any other way.
Want to create your own Bitcoin fork? With the coupon code “GreatLeaderCraig”, Bitcoin Magazine readers get 50% off for the next 6 days. (Make sure to double check that this discount is really subtracted before making the payment; the Forkgen website was having some issues at the time of writing this article.)
Finally, Bitcoin Magazine does not endorse using this service: We cannot guarantee the authenticity of Forkgen or its software in any way.
The post With Forkgen, Anyone Can Now Create Their Own Bitcoin Fork (Even Us) appeared first on Bitcoin Magazine.
Bitcoin is usually not considered the blockchain best suited for self-executing conditional payments, better known as smart contracts. While it does support basic programmability to enable features like time locks and multi-signature (multisig) schemes, competing projects like Ethereum, Ethereum Classic or Qtum are often expected to better support more advanced applications.
However, a new wave of research is increasingly questioning this assumption. For example, Scriptless Scripts, a project spearheaded by Blockstream mathematician Andrew Poelstra, cleverly utilizes the magic of cryptography to move smart contracts off-chain, while leveraging Bitcoin’s security, but without requiring extensive smart-contract support on the Bitcoin protocol itself.
Along similar conceptual lines, Discreet Log Contracts (DLCs) could deploy another class of smart contracts on top of Bitcoin. A project by one of the authors of the original Lightning Network white paper, Tadge Dryja, and recently presented at Scaling Bitcoin Stanford, DLCs could realize blockchain-enforced insurance companies, futures contracts, dollar-pegged coins and much more.
Here’s how that works.
Many types of smart contracts essentially boil down to “bets.”
Let’s say, for example, that someone wants to insure himself against being unable to travel due to a potential pilot strike. That person can then “bet” there will be a strike. If there is no strike, the “bet” is lost as if it were an insurance down payment. If there is a strike, on the other hand, the “bet” is won, like an insurance payout.
As a more interesting example perhaps, people can also bet on the price of BTC relative to the US dollar: a futures market. If someone bets that the BTC price will go down, and the BTC price does go down, he “wins” more BTC; if the BTC price goes up, he “loses” some BTC. Interestingly, this can be structured to ensure that the person entering into these “bets” is practically guaranteed to end up with the same USD value in BTC regardless of what happens. This can, in turn, be used to realize a “stablecoin” with fixed USD value on Bitcoin’s blockchain. (It should be noted that there are extreme examples where this doesn’t hold up, like a scenario where Bitcoin fails completely and BTC drops to zero dollars — but, in most cases, it works.)
However, while these types of smart contracts are interesting, they cannot be executed based on blockchain-based data alone. A blockchain cannot tell whether pilots are striking, nor what the USD/BTC exchange rate is. This requires data input from outside of the blockchain, and this is where “oracles” come in.
Oracles are essentially trusted sources of information; they provide data that cannot itself be “read” by a blockchain. This data can be inserted into a smart contract, which will then execute based on the oracle’s input.
Since the types of smart contracts described above need to rely on such external data sources anyway, it makes sense to leverage the trust in oracles in order to simplify a smart contract. Instead of more complex solutions, oracles can, for example, be “plugged into” a relatively basic multisig scheme.
As a simple example, let’s say that next summer Alice and Bob want to bet a bitcoin on the FIFA World Cup final between Argentina and Brazil. Alice thinks Argentina will win; Bob thinks Brazil will. To make this bet blockchain-enforceable, Alice and Bob both send one bitcoin to a multisig address that requires two of three signatures to spend the coins. One of these three keys is held by Alice, another key is held by Bob and the third key is held by the oracle.
If Argentina wins, Alice and Bob should both sign a transaction from this address that sends both bitcoins to Alice. Since this requires only two signatures, Alice and Bob’s signatures suffice, and the oracle never comes into play. (Needless to say, if Brazil wins it’s the other way around: Alice and Bob sign a transaction sending both coins to Bob.)
A problem arises only when the losing party — Bob — refuses to sign the transaction. It’s in this scenario that the oracle would use its third key to help Alice claim the two bitcoins. Importantly, exactly because this is an option, Bob really has no reason not to sign. (This is even more true if Alice and Bob put up some collateral so Bob gets refunded some of his BTC if he signs.)
Ideally, the oracle’s signature should hardly ever be needed at all; Alice and Bob can complete the bet on their own.
Still, the basic multisig and oracle solution has its weaknesses. For example, the oracle would probably have to be involved with setting up the bet; or at least it should be available to act as a sort of judge whenever needed. This means that the oracle could potentially be corrupted, for example, if Bob offers the oracle a share of the coins if they collude to steal both. And Alice and Bob also have no privacy from the oracle: the oracle will know exactly what they are betting on and how much they are betting. Meanwhile, the rest of the world can tell that Alice and Bob used an oracle for their bet (and, therefore, that it was a bet).
These are the problems that Discreet Log Contracts could solve. They maintain the benefits of the straightforward multisig and oracle solution — but eliminate most of its weaknesses.
As mentioned, Dryja, who is currently working for MIT Media Lab’s Digital Currency Initiative, is one of the authors of the lightning network white paper. His DLC project is based on a similar concept.
A key idea behind the lightning network is that two people can open a payment channel, allowing them to transact with each other. Such a payment channel utilizes Bitcoin’s basic programmability (like time locks and multisig addresses) and combines it with some clever tricks to commit transactions to other transactions, all without broadcasting them to the network unless needed.
Over time, as the people in the channel transact with each other, these payment channels are updated with new balances or “channel states.” Either party can then “drop” the latest channel state on the blockchain at any time and claim their balance whenever they want to. And importantly — this is where Bitcoin’s basic programmability is leveraged — both parties can only safely broadcast the latest channel state. If they try to cheat by broadcasting an earlier channel state, their counterparty can actually claim every single coin in the channel.
DLCs works similarly. But where a lightning network payment channel only lets the parties involved broadcast the most recent channel state, DLCs limit them to broadcasting only the channel state reflecting the correct outcome of a bet.
This is where the oracle comes in — but this time combined with some fancy math tricks.
As opposed to 2-of-3 multisig schemes where oracles act a bit like judges, oracles in DLCs more closely resemble broadcasters. For our World Cup bet, it would make sense that the oracle is a sports-betting service, a football news website, perhaps the FIFA or another entity that broadcasts the winner anyway and that is reasonably trusted not to lie about it.
Let’s say the oracle in this case is a sports-betting service that regularly publishes the score and winner of the World Cup final on their website. To enable a DLC, the same sports-betting service only needs to add a minor additional step.
Basically, this “broadcast oracle” has a public key and a private key. (A private key is really just a randomly generated number, while the public key is a seemingly random number derived from that private key.) This public key is published somewhere, most likely on the betting service’s website for anyone to find. The private key is, of course, kept private: This can be used by the oracle to sign a message. (Such a signature, too, is a seemingly random number but is derived from the private key in combination with the message.)
The possible outcomes of the bet are known as well: either Argentina wins the World Cup final or Brazil wins. The sports-betting service, therefore, announces that it will broadcast one of two very specific messages: “Argentina won” or “Brazil won.”
Now, what’s interesting about public key cryptography is that the sports-betting service’s public key can be used to figure out what a signature of the message — “Argentina won” or “Brazil won” — will mathematically “look like.” (“Look like,” in this case, doesn’t mean that Alice and Bob can produce the signature themselves, but they can calculate certain mathematical properties that it will have.)
Because Alice and Bob can calculate what the potential oracle signatures will “look like,” they can use it in their DLC.
First, before the World Cup final, Alice and Bob pay one bitcoin to a “funding transaction.” From this funding transaction, several potential transactions are constructed — but these are not yet broadcast over the network.
Here’s where the cryptography gets a bit complex.
What the sports-betting service signatures “look like” is cleverly embedded in these several potential transactions, where each potential signature enables a different transaction. (Specifically, and somewhat unconventionally, what the signatures “look like” is used as public keys in key-pairs for the different transactions.)
In other words, knowing what the oracle’s potential signatures will “look like,” Alice and Bob can construct their payment channels such that the two different potential signatures can be used to validate two different channel states: one where Alice gets two bitcoins and one where Bob gets them.
Then, the actual oracle signature, which is published after the World Cup final is played, is used as private key to validate the winning transaction — and only the winning transaction. If the sports-betting service broadcasts a signature for “Argentina won,” Alice can take this signature, use it as a private key (in combination with her own private key) and claim the two bitcoins from the channel. If the oracle signs a message for “Brazil won,” Bob can. Meanwhile, if either tries to claim the bitcoins without the oracle signature, they will fail, and their counterparty can instead claim both coins.
Further, like lightning network payment channels, the outcome of the bet — two bitcoins for Alice if Argentina wins — can now also be broadcast by Alice and Bob as a fairly regular multisig transaction from the funding transaction. And indeed, exactly because Alice can enforce the outcome with the oracle signature anyway, there is little reason for Bob not to cooperate.
As a result, the “bet” is fully blockchain-enforced through the sports-betting service’s signature, while this service doesn’t need to do anything for this specific bet; it doesn’t even need to know it ever took place.
And, notably, while this bet is relatively simple (either Argentina wins or Brazil wins), in reality DLCs could allow for far more complex scenarios. Exactly because only a fairly regular multisig transaction is broadcasted in the end, it doesn’t really matter if a “bet” has two, 200, or 200,000 potential outcomes.
For more details on DLCs, also see Dryja’s presentation at Scaling Bitcoin Stanford.
The post This Lightning Network Designer Is Re-Inventing Bitcoin Smart Contracts appeared first on Bitcoin Magazine.
The post Bitcoin’s Journey from $1,000 to $10,000: The Stories That Got Us Here appeared first on Bitcoin Magazine.
Bitcoin’s capacity is limited. Meanwhile, smart contracts can be resource intensive. So even though Bitcoin has always supported basic smart contract functionality, the two have never been a natural match.
But a recent topic of research spearheaded by Blockstream mathematician Andrew Poelstra could help fix this. Recently presented as key part of his presentation at Scaling Bitcoin Stanford, “Scriptless Scripts” have the potential to completely move certain smart contracts off of Bitcoin’s blockchain — while still leveraging all of Bitcoin’s security.
Smart contracts, first proposed by digital currency veteran Nick Szabo in the 1990s, are essentially self-executing contracts. Most typically, they send money from someone to someone else if specific conditions are met. For example, if someone streams a song, a payment is automated from the streamer to the artist.
While smart contracts are often associated with “second generation” blockchains like Ethereum, Bitcoin has always supported basic smart contracts, too. In a way, any Bitcoin transaction is technically a smart contract: Funds are typically moved on the condition that a valid cryptographic signature is provided. Slightly more advanced smart contracts — such as multisig and timelocks — are used to enable second-layer protocols like the Lightning Network.
But there are problems with blockchain-based smart contracts. For one, as they grow more complex, they require more resources to execute. This is especially problematic because all nodes on the network need to execute the contract — not just the parties involved with the contract itself.
This network-wide execution also means that the parties involved have no privacy regarding what their smart contract entails: The entire network will know exactly what it looks like. By extension, this is bad for fungibility as well. If the smart contract is unpopular for some reason, the funds involved — publicly visible on the blockchain — are tainted.
As smart contracts become more complex, they can even become a security risk. Alternative software implementations might, for example, interpret details of contracts slightly differently, making it harder to keep all nodes on the network in consensus. And potential bugs in these smart contracts are public as well, which increases the chance of hacks.
But Poelstra, among others, thinks that many of these problems can be solved by actually moving the bulk of contracts off of the blockchain. Instead of having all nodes on the network calculate the entire smart contract, only the parties involved with the contract should perform this function.
The trick is to ensure that the rest of the network does still correctly enforce the outcome of the contract: The payment must only be made if the required conditions are met.
Poelstra originally began researching “Scriptless Scripts” (a phrase he also coined himself) in the context of the Mimblewimble protocol. This stripped down version of Bitcoin offers more privacy and better scalability but does not support script: the bits of code embedded in Bitcoin transactions that allow for most basic smart contract features.
So, Poelstra figured out how to get the utility offered by scripts without actually requiring them on the blockchain: Scriptless Scripts.
The key to Scriptless Scripts is that (fairly) regular cryptographic signatures can indirectly reveal something that’s not part of the transaction that includes the signature. In other words, when someone signs to validate an ordinary Bitcoin transaction, it holds that a smart contract that is not hosted on the blockchain still executes faithfully.
This is made possible with Schnorr signatures. These types of signatures are not yet implemented on the Bitcoin protocol, but it is possible that they could be deployed within a year or so from now.
Schnorr signatures allow for signature aggregation; several signatures can be mathematically combined into a single signature. And, importantly for this use case, this math is “linear.” This basically means it’s possible to perform relatively straightforward but very expressive math on these signatures.
Oversimplified, it works something like this:
Private keys and signatures are, of course, really just numbers, where the latter is derived from the former. Since this is a simplified example, let’s say one private key looks like 10, and half of the Schnorr signature derived from that private key looks like 10000. And the other private key looks like 15, with the second half of the Schnorr signature looking like 15000. In this simplified example, the Schnorr signature would then look like 25000 (or 10000 + 15000).
And since both halves of the signature are just numbers, it’s possible to perform math between them. For instance, in this simplified example, the difference between these halves is 5000 (or 15000 – 10000).
While the reality is more complex, Schnorr’s linearity allows for several of these kinds of math “tricks.”
Now let’s say that a streamer wants to listen to a song by an artist. The artist has the right to this song, and it will play for the streamer if (and only if) the artist’s signature is provided to a server where the song is hosted. Since we’re simplifying, let’s say that this “song signature” looks like 7000. The streamer is willing to pay the artist one bitcoin for this song signature, to listen to the song. (He wants to listen to the song really badly.)
In this simplified example, the streamer and the artist can automate this trade by doing two things. First, they create a fairly normal Bitcoin transaction that sends one bitcoin from the streamer to the artist, if the streamer and the artist both provide their half of a Schnorr signature to create a full Schnorr signature. (In reality, this step requires some extra safety precautions to ensure no one loses money, but it is relatively simple.)
The next step is where it gets a bit more complex.
The artist knows what her half of the Schnorr signature looks like; since we’re simplifying, let’s say it looks like 8000. And she knows what her song signature looks like: 7000. As such, she can calculate the difference between these two: 1000. This is called the adaptor signature. The artist then hands this adaptor signature — 1000 — to the streamer.
Here’s where the cryptographic magic happens.
By modifying the ordinary signature verification method, the streamer can actually verify that the adaptor signature he just received (1000) is indeed the difference between the artist’s half Schnorr signature and her song signature — even though the streamer does not have access to either signature yet. (And thanks to cryptographic tricks called “zero-knowledge proofs,” something like this can actually be done in a surprisingly broad range of scenarios, not just in signatures as this example portrays.)
Now, having verified that the adaptor signature (1000) checks out, the streamer can, in turn, give his half of the Schnorr signature to the artist because once the artist uses the streamer’s half to create a full signature and broadcasts this over the Bitcoin network, she automatically reveals her half of the Schnorr signature (8000) to the streamer as well.
Using the artist’s half of the Schnorr signature, the streamer can now subtract the adaptive signature: 1000. By subtracting the adaptive signature from the artist’s half Schnorr signature (8000 – 1000) the streamer indeed learns the artist’s “song signature”: 7000. And now he can listen to the song.
In other words, by broadcasting the transaction that pays her one bitcoin, the artist automatically sells the streamer the signature: a smart contract.
From the perspective of the blockchain — that is, the rest of the world — the transaction is quite regular. Nothing about the smart contract, other than the “settlement transaction,” is ever recorded on the blockchain. No one will ever know that an underlying contract was executed — never mind what song the streamer listened to — and the contract-related data never needs to be calculated or stored by anyone other than the parties involved.
To see Poelstra’s Scaling Bitcoin presentation that includes Scriptless Scripts, “Using the Chain for What Chains Are Good For”, click here. An alternative, in-depth explanation of Scriptless Scripts was published by JoinMarket developer Adam “Waxwing” Gibson and can be found here.
The post Scriptless Scripts: How Bitcoin Can Support Smart Contracts Without Smart Contracts appeared first on Bitcoin Magazine.
BtcDrak, the most active pseudonymous Bitcoin Core contributor to date, is making a move into the mining hardware industry. The developer, who besides having contributed to the Bitcoin Core repository also maintains the bitcoincore.org website and the Bitcoin Core Community Slack channel, has helped set up ASIC chip manufacturing company Halong Mining over the past year. The startup has now produced an initial batch of mining hardware and plans to ship to consumers in early 2018.
“We started a mining project with the aim to bring much needed competition to the market,” BtcDrak told Bitcoin Magazine. “We want to ‘make SHA256 great again.’”
Halong Mining is launching a production line that consists of one machine for now: the DragonMint 16T. The miner — its name references the Dragon’s Den, an (in)famous private chat channel on the Bitcoin Core Community Slack — is equipped with newly designed chips and can produce a total of 16 terahashes per second. Importantly, BtcDrak claims that the machines are about 30 percent more energy efficient than the most efficient ASIC miner on the market right now, Bitmain’s AntMiner S9.
“The DragonMint will be the most advanced miner to date,” he said.
The main bottleneck to entering the ASIC market is typically capital: developing specialized chips from scratch is expensive. While BtcDrak preferred not to disclose much information about Halong Mining for now, he did note that the machines have been produced by a team with “serious expertise.”
According to the developer, Halong Mining has invested $30 million in research and development so far, with over 100 people involved, including chip designers, electronics hardware specialists and software designers.
“Research and development is not cheap, and we need a lot of diverse skills,” BtcDrak explained.
Halong Mining has now produced an initial batch of DragonMint machines, though these are still just prototypes for testing and fine-tuning. They will not be sold to the public due to risk of reverse engineering, BtcDrak said, though he emphasized that the machines are working.
“Other companies that want to enter the ASIC mining industry develop everything in simulations, and then the first presale batch tries to pay for small production. But the NRE [non-recurring engineering] and making wafers is fraught with difficulty; the first run is not easy to do well.”
Halong Mining published a video of a DragonMint on YouTube today. BtcDrak thinks the first mass-produced run of DragonMint miners will happen within about four months and begin to ship in March of 2018.
Apart from the DragonMint machines, Halong Mining will also be selling mining chips separately, in bulk.
With the introduction of DragonMint miners, Halong Mining will offer an alternative for Bitmain’s mining hardware, which has dominated the market for the past few years. An estimated 70 percent or more of the hash power on the network today is produced by Bitmain machines, and around half of all hash power is pointed to mining pools that are either owned by or closely affiliated with Bitmain, such as AntPool, BTC.com, ConnectBTC and ViaBTC.
“One manufacturer as a monopoly is not good for Bitcoin,” BtcDrak said. “Centralization in mining is a problem regardless of how benevolent you are. If there is a center, then governments and criminals can attack it. Decentralization protects the entire system and all its participants. So I wanted to bring competition.”
Bitmain in particular has also not made itself popular within segments of the Bitcoin community over the past years. The Chinese ASIC manufacturer was at the center of the AsicBoost and Antbleed controversies, and perhaps more importantly, some speculate that the company exerted its influence over the mining ecosystem by allowing or limiting hardware sales based on how hash power from the machines was used. Bitmain has always denied this is the case, however.
Halong Mining wants to distribute ASIC miners “far and wide to help decentralize mining,” BtcDrak said, adding that the company is considering open sourcing its board designs and software. This would help new manufacturers get a foothold in the industry, building on the research already done by Halong Mining over the past year.
“There is a lot at stake here. A lot of time and money has been invested … and we have a huge opportunity to bring more diversity to Bitcoin mining, and in turn help secure the network more.”
The post This Bitcoin Developer Is About to Take on the Mining Hardware Industry appeared first on Bitcoin Magazine.
In case there were any remaining doubts, it now seems clear that the SegWit2x hard fork will not happen.
The SegWit2x project, a product of the New York Agreement signed onto by a long list of companies and miners in May, had scheduled a hard fork to double Bitcoin’s block weight limit today. And while the controversial effort was suspended by leaders of the project last week, this would not have stopped anyone else from proceeding with it. Companies like Coinbase were indeed taking into account that the SegWit2x hard fork could still happen.
SegWit2x nodes — most notably btc1 — were programmed to fork away from the Bitcoin blockchain this afternoon (UTC) to create the SegWit2x blockchain and a new currency, often referred to as B2X. However, not a single SegWit2x block has been mined since fork point, nor is there any indication that this is likely to happen. For all intents and purposes, there is no SegWit2x — nor a B2X.
Further, software bugs in the btc1 codebase made all btc1 implementations grind to a halt even before it reached the expected fork point. While Bitcoin and SegWit2x nodes were widely expected to share a single blockchain up until block 494783 and then to go their own ways at block 494784, btc1 nodes never made it past block 494782.
This is mainly because the first block on the SegWit2x chain was required to have a “base block” larger than one megabyte. This is how the chain would diverge from the original Bitcoin protocol. But due to what is referred to as an “off-by-one error,” SegWit2x blocks started to reject smaller-than-one-megabyte blocks one block too soon — at block 494,783 instead of 494,784.
Moreover, another btc1 bug prevented miners from mining a big enough block when it was needed. So even if some miners did want to proceed with the fork, they accidentally wouldn’t have done so — at least not automatically. Miners would instead have had to manually configure their block weight settings, but it’s unlikely they knew about this step. Btc1 maintainer Jeff Garzik (while also denying there was a problem) has since released a patch to resolve this issue.
But judging by the absence of any SegWit2x blocks, the patch hasn’t made a difference, most likely because few, if any, miners were interested in mining on the SegWit2x chain in the first place.
Despite the seeming failure of SegWit2x to take off in any way, it should be noted that there is technically no way to declare a fork like SegWit2x officially “dead” or “failed.”
While unlikely, it’s always possible that the SegWit2x hard fork could proceed at some point in the future. In fact, there is no way to tell whether the SegWit2x chain is currently being mined with a little bit of hash power right now, and it is strictly impossible to foresee whether it will be mined later on. Perhaps a SegWit2x block will be found a day from now, a week from now or even ten years from now, at which point SegWit2x and B2X will technically come into existence.
However, since the SegWit2x chain did not include a mining difficulty reset, it will be as hard to mine a B2X block as it currently is to mine a BTC block. Meanwhile, market support for B2X appears to be extremely low, with B2X futures trading below 2 percent of BTC. So even if miners decide to mine B2X blocks, they’d almost certainly be earning far less than they would by mining BTC. Or, more accurately, they’d spend more on electricity bills than they’d be able to earn by mining B2X. The financial incentive to mine the SegWit2x chain just isn’t there.
Alternatively, SegWit2x could see a bit of a rebirth in the form of “BitcoinX” (BTX). This project, supposedly started by disappointed SegWit2x supporters, will take a snapshot of bitcoin balances at block height 494,783 and start a SegWit2x-like altcoin that offers all BTC holders the equivalent amount in BTX. Though, while this coin is arguably more viable than B2X thanks to a mining difficulty reset and more, it really is a new coin — arguably even more so than B2X would have been.
The post Now the SegWit2x Hard Fork Has Really Failed to Activate appeared first on Bitcoin Magazine.
Although still in testing phase, the lightning network can now be used to send transactions across different blockchains. The Lightning Labs development team successfully swapped testnet bitcoin for testnet litecoin through a lightning channel this week: ownership of the coins changed hands, while no transaction was recorded on either blockchain.
“Previous atomic swaps that I have done were on-chain, and had the on-chain limitations of slow [transactions] and high transaction fees,” Litecoin creator Charlie Lee told Bitcoin Magazine, referring to an older trick to exchange different types of coins trustlessly. “Off-chain atomic swaps are significantly better. They are instant, [have] low fees, and better protect one’s privacy.”
The successful test paves the way for trustless cryptocurrency exchanges, near-seamless multi-coin payment processors and more.
The lightning network is the highly anticipated second-layer payment network to be deployed on top of Bitcoin. And as an open protocol, it’s relatively easy to deploy lightning network support for other cryptocurrencies that are forked from Bitcoin’s codebase — like Litecoin.
Interestingly, if the lightning network runs on different blockchains, these chains can effectively be linked together. If one or several peers on the network are willing to take one type of coin and forward another, it’s possible to send bitcoins on one end of a channel that will end up as the equivalent in litecoin on the other end.
In a Medium post published in the first week of 2017, Lee explained that this potential to create these kinds of “bridges” between cryptocurrencies made him throw his weight behind the Segregated Witness (SegWit) soft forks on both Litecoin and Bitcoin.
When SegWit activated on Litecoin last spring, Lee’s vision came one step closer to reality. Because the soft fork had not yet activated on Bitcoin at that time, Lightning Labs decided to add Litecoin support to their LND lightning network implementation. Thus, by the time SegWit activated on Bitcoin last summer, LND was already compatible with both chains.
The testnet versions of these two blockchains are now made interoperable through the lightning network for the first time, allowing users to swap one type of coin for the other.
“The primary advantages over previous solutions are speed, cost and privacy,” Lightning Labs developer Conner Fromknecht told Bitcoin Magazine. “Transfers are more or less instant, and don’t require the cost of an on-chain transaction. Additionally, in the cooperative case, the transactions are never broadcast, and leave no trace on the blockchain, offering privacy benefits. And with any luck, these privacy benefits will only continue to improve.”
This week’s specific test was done on a local machine, on which Fromknecht himself created two nodes: “Alice” and “Bob.” These two nodes were modified to be able to monitor both the Bitcoin and Litecoin testnets. Fromknecht then created a single lightning channel that sent testnet litecoin from Alice to Bob and testnet bitcoin back from Bob to Alice at a fixed exchange rate. While still all in an experimental setting, the test was successful; Lightning Labs today published a blog post and a video detailing the results.
In addition to offering a faster, cheaper and more private solution to exchanging coins, the successful test paves the way toward a whole new range of possibilities in the context of the lightning network. For example, peers on the network could eventually act as cryptocurrency exchanges, competing with one another to offer the best exchange rates.
“Arguably the most important benefit of Lightning swaps is the ability to efficiently exchange different currencies without a custodian,” Fromknecht said. “Our ecosystem heavily depends on exchanges to fulfill this role today, but Lightning swaps offer users a choice to get the best of both worlds — instant exchanges without relinquishing control of your money.”
Similarly, such exchangers could act as payment processors: it would be much easier for users to spend litecoin at merchants that only accept bitcoin (or vice versa). And it’s even conceivable that bitcoin-to-bitcoin payments over the lightning network will route via Litecoin hubs, if that’s the cheapest way to get funds from A to B.
For Lee, at least, this is not as unlikely as it sounds, and the successful tests mark another step toward his vision for the lightning network on Litecoin and Bitcoin.
“The Litecoin team is excited to work with Lightning Labs to explore the true potential of instant cross-chain atomic swaps,” he concluded.
For a more in-depth technical explanation of these kinds of atomic swaps, see our previous article “Atomic Scaps: How the Lightning Network Extends to Altcoins” or the blog post and video published by Lightning Labs today.
The post The Lightning Network Now Supports Transactions Across Blockchains appeared first on Bitcoin Magazine.
This is a re-write of “A Beginner’s Guide to Claiming Your ‘Bitcoin Cash’ (and Selling It)”. Please note: Everything in this article is just advice based on our best understanding of the current situation.
Bitcoin Gold (also referred to as Bgold, and trading under the ticker BTG) launched November 12, 2017. Since the Bitcoin blockchain technically forked on Bitcoin block 491407, anyone who held bitcoin (BTC) on October 24, 2017 should have an equivalent amount of BTG attributed to their Bitcoin private keys.
In our beginner’s guide to surviving the Bgold and SegWit2x forks, we explained how to secure your private keys so you could be sure to access your BTG and B2X. The B2X fork has since been suspended by the leaders of that project, however, and it currently seems very unlikely to happen in any serious way.
As such, this follow-up article explains how you can claim (and potentially use) your BTG — only your BTG.
Good news: Bitcoin Gold enforces strong replay protection. This means you can’t accidentally spend your BTC when you mean to spend BTG or vice versa.
As such, if you don’t care about BTG at all right now, you don’t need to do a thing. You can just keep using bitcoin as you always have. If you ever change your mind (and don’t lose your Bitcoin private keys in the meantime), you can still claim your BTG at any point in the future.
Likewise, if you want to hold onto your BTG long term, you also don’t need to do anything right now. You can keep using BTC as if nothing happened; just make sure to never lose your private keys.
(In both these cases, however, it could come in handy to keep a record of the Bitcoin addresses that stored your bitcoins at the time of the split. This is not strictly necessary, but your future self may thank you if you do it. You should be able to find this information in your wallet of choice, though where you find it may differ a little bit from wallet to wallet. Alternatively, you could move all your coins to a new address. If you then look up all your transactions since October 25, 2017, and note which addresses spent coins since that date, you know which addresses held coins at the time of the split.)
Now let’s assume you do care about BTG right now, at least enough to want to sell your share. (1 BTG is trading around 0.02 BTC at the time of writing of this article, so you could earn a 2 percent “dividend” on your BTC if you decide to sell.)
If you followed the advice outlined in our beginner’s guide, the good news is that you should be in full control of your Bitcoin private keys. This means you now hold BTC as well as BTG.
The bad news is that it’s not necessarily easy or safe to claim your BTG. If you’re using insecure (or even malicious) software, you may accidentally expose your private keys. And because these are the same private keys that secure your BTC, this exposure could lead to your BTC being stolen. You stand to lose much more from losing your BTC than you stand to gain from selling your BTG.
Therefore, you are going to want to take your time and make sure you understand what you are doing well enough to do it without exposing your private keys. Your BTG isn’t going anywhere.
In our beginner’s guide to surviving the Bgold (and SegWit2x) forks, we explained how to secure your private keys and recommended different wallet options. Here, you can find, per option, how to access your BTG.
Note that while it’s not strictly necessary in all cases, it’s probably best to first move your bitcoins (BTC) to a new address, or even a whole new wallet with a new seed, before you even touch your BTG. This way you don’t add any security risks, while it’s potentially also a bit better for privacy. (More on this below.)
The first recommendation in our beginner’s guide to surviving the Bgold (and SegWit2x) forks was to use a paper wallet. This advice was given in the context of storing your coins long term in particular. But if you want to access your BTG, you can, of course, do this right away.
However, the point of a paper wallet really is that your private keys are not stored in any device that could be hacked. Therefore, if you’re going to upload your private key into a Bitcoin Gold wallet, you should definitely create a whole new paper wallet with a new private key for your bitcoin (BTC). It’s probably best to then first sweep your private keys with a Bitcoin (BTC) wallet, and then send the coins to this new paper wallet for BTC.
Electrum and Coinomi are two wallets that allow you to sweep Bitcoin private keys. Look for the “sweep” option in the menus of these wallets; that’s where you can scan the QR-code displayed on your paper wallet. (Alternatively, you could type in the private key.) Once you’ve done this, send the bitcoins to the new paper wallet.
Once your bitcoins are stored safely on the new paper wallet (ideally after at least one confirmation), the old paper wallet still holds the BTG.
Now, the same trick must be repeated to access your BTG. Electrum does not support BTG, but Coinomi does. Coinomi also published a blog post explaining exactly how to access your BTG. This includes instructions for paper wallets.
Our second recommendation was to use a regular wallet, as listed on bitcoin.org.
How to access your BTG if you were using a regular wallet differs from one wallet to the next. But in most cases, Coinomi is once again the best wallet to import your keys into. While originally written for Bitcoin Cash, this Coinomi blog post explains exactly how to make that switch for a number of wallets. (Just mentally replace “BCH” for “BTG” wherever relevant.)
These wallets store your private keys in a dedicated folder on your computer. You can make a backup of this folder using the menu in your wallet and select “Backup wallet.” Once you’ve done this, you should be able to import this backup into the Bitcoin Gold full node, Bitcoin Gold Core.
But once again, it’s a lot easier (and possibly even safer) to export your private keys from your Bitcoin full node and import them into the Coinomi mobile wallet. While originally written for Bitcoin Cash, this Coinomi blog post explains how to do that for BTG as well. (Just mentally replace “BCH” for “BTG” wherever relevant.)
We also recommended using a hardware wallet to keep your private keys secure — though we also noted that these wallets don’t necessarily make it easy to access your BTG.
Indeed, at the time of writing, no hardware wallet has enabled access to BTG. However, Ledger and Trezor have published blog posts indicating that they will be working on it. If you use either of these wallets, keep an eye out for announcements on their social media or blogs. Digital Bitbox and Keep Key have also published blog posts on the Bgold fork, suggesting they might support it; but they don’t support it yet. Keep an eye on their social media and blog to see if that changes.
If you did not follow our advice and instead stored your BTC in any other wallet, or on an exchange, or anywhere else, you may or may not still be able to claim your BTG. In this case, you’ll have to figure out for yourself whether this is the case or not, and how to do so. This Coinomi blog post may, once again, be of help for some wallets. (Just mentally replace “BCH” for “BTG” wherever relevant.)
Once you have claimed your BTG, you can use it however you please. Just like any other altcoin, you could, for example, sell it for BTC or perhaps spend it somewhere if it’s accepted for payment, etc.
If you decide to sell your BTG, there are a number of exchanges where you can do this. The Bitcoin Gold website lists most of them here. (Which of these you decide to trust is up to you; we’re not giving any particular advice.)
But there are three more factors to keep in mind before doing so.
The first factor is privacy. Your public keys (which are linked to your BTC and BTG addresses) are identical for BTC and BTG. This means that whenever you spend your BTG (for example, to send them to an exchange), you do not only reveal your BTG addresses but also your BTC addresses. This can, in turn, reveal a lot about your current holdings as well as your past and future transactions and can even, by extension, reveal other data about people or entities you transact with. Make sure you are comfortable with giving up this privacy if you are going to send your BTG to an exchange or anywhere else.
The second factor is mostly theoretical at this point but worth a quick mention nonetheless: security. By revealing your public key when spending BTG, you strip away one layer of cryptographic security, even for your BTC addresses. This doesn’t mean that your BTC are insecure right now, but there is an increased chance that your BTC won’t be secure at some point in the (far) future when this particular cryptographic standard is weakened. It is, therefore, best to move your BTC to a new address, at least some time within the next couple of years.
The third factor was already mentioned but bears repeating: If you’re using insecure software to claim your BTG, your BTC may be at risk. It’s probably best to move your BTC to a new address or even a whole new wallet with a new wallet seed before you even start meddling with BTG — regardless of which wallet you were using. That way, if you do mess up with insecure BTG software, you shouldn’t lose your BTC.
1. You don’t have to do anything if you don’t want to, and there is no rush. If your private keys are secure, your BTG is secure.
2. If you want to use your BTG in any way, it’s probably best to first move your BTC to a whole new address that you control, or even to a whole new wallet generated from a new seed. (But don’t lose your old private keys or seed: These still hold your BTG!)
3. Once you know what you’re doing, upload your private keys into a Bitcoin Gold wallet, like Coinomi. Then you can keep it, spend it, perhaps send it to an exchange to sell or whatever it is you want to do with your “free money.”
The post A Beginner’s Guide to Claiming Your Bitcoin Gold (and Selling It) appeared first on Bitcoin Magazine.
After weeks of preparation, Bitcoin Gold (Bgold; BTG) is finally launching tomorrow, November 12, 2017.
Bitcoin Gold is the second project to fork away from the Bitcoin blockchain to create a new coin this year; on August 1, Bitcoin Cash (Bcash) was the first. Where Bcash attempted to offer an on-chain scaling solution by increasing Bitcoin’s block size limit (while removing the Segregated Witness code), Bgold is an attempt to counter Bitcoin’s mining centralization.
The most important difference between Bitcoin and Bitcoin Gold is a new proof-of-work mining algorithm. Instead of SHA256, the new coin uses the memory-hard Equihash proof-of-work function that’s also used in the privacy-focused altcoin Zcash. This means that specialized ASIC hardware that has come to dominate Bitcoin’s mining ecosystem will not be able to mine Bgold.
Although Bgold is launching this weekend, the fork “officially” occurred on October 25. Anyone who held bitcoin (BTC) on that day (specifically, when Bitcoin block 491406 was mined) will have an equivalent amount of BTG attributed to their private keys. These private keys can be imported into a dedicated Bgold wallet, which, starting tomorrow, will allow users to spend the coins. (But note that this does not come without risks and tradeoffs: If you’re not sure what you’re doing, it’s best not to ignore BTG until you do. For more information als see this article.)
Block 491407 on the Bgold blockchain wil be the first block to deviate from the Bitcoin protocol. In other words, this will be the first block where Bgold splits off to become its own currency. However, somewhat controversially, the first 8000 blocks will be privately mined by the Bgold team. Only after these 8000 blocks will Bgold’s mining difficulty ramp up to normal levels, and will anyone be allowed to mine the coin. The resulting 100,000 BTG worth of block rewards will pay for project development and more. (For more details, see the Bitcoin Gold roadmap.)
Other changes implemented by Bitcoin Gold are mostly to ensure a smooth split away from Bitcoin. This includes a new difficulty re-adjustment algorithm named “DigiShield” that adjusts the mining difficulty each time a block is found — instead of once every two weeks. Bgold also includes strong replay protection, ensuring that no users spend BTC when they mean to spend BTG, and vice versa. Additionally, BGold implemented a new address scheme, preventing users from spending BTC to BTG addresses and vice versa.
Bitcoin Gold will be supported by a relatively large number of exchanges, including major players like Bitfinex, OKex and HitBTC. Several of these exchanges are effectively supporting BTC/BTG trading already through futures markets. Ignoring an initially inflated price, these futures have traded at around 0.02 BTC in recent weeks, with a notable surge to about 0.042 BTC over the past few days. If this holds up, 1 BTG would be worth almost $250, and Bgold would immediately become a top-5 altcoin on websites like coinmarketcap.com.
For more information on Bitcoin Gold, see Bitcoin Magazine’s earlier article on this project.
Disclaimer: The author of this article holds BTC and will therefore also own BTG at launch.