The Bitcoin Cash (BCH) chain often advertises how it can upgrade using hard forks (usually indicating how easy it is). 

It sounds all well, but in order to do this, you must have centralized control over the chain such that these hard forks can be pushed down to all clients.  If clients (i.e. miners) don't upgrade their code, then they will be working on the old chain while everyone else moves on.

With centralization comes risk.  The risk that a person or entity in control can act in a way that is not a consensus decision.  This is exactly the risk that has materialized on BCH.

Amaury Séchet is the lead developer of Bitcoin ABC (the reference implementation for BCH).  He announced that in November 2020 there will be an upgrade on BCH.

He plans to try another "fix" for the BCH difficulty adjustment algorithm (DAA) which by the way suffers from low hashpower in comparison to BTC - and miners "gaming" the chain.  I'm not going to comment on the issues with the DAA here - the second change is the real point of issue.

The second improvement is the addition of a new Coinbase Rule.

How can the coinbase rule be "improved" you ask?

The Coinbase Rule improvement is as follows: All newly mined blocks must contain an output assigning 8% of the newly mined coins to a specified address.

And who owns that address?  - yes, the developers (Amaury).  Basically, they are taxing each new block with an 8% tax rate. 

Ask yourself - how can this be the consensus.  Well, it isn't.  And I hope it is clear at this point that BCH is NOT a decentralized currency.

Does this sound like Bitcoin to you?

Hello everyone!

I thought I should write a quick post since I haven't done so in a while.  I'm still alive ;)  

In the past few weeks, I've been busy working on a project related to COVID risk.  I've learned quite a bit recently about virology and how to model epidemics.  One of the most notable things was the bimodal nature of the disease (where many cases are asymptomatic) means it is challenging to contain or know the prevalence.

Now that there are a few serology studies released, we are beginning to see that the disease has affected more people than previously reported.  The good news there is that the infection fatality rate (IFR) is likely not as high as the worst-case estimates, but it's still very significant for the older population.  If someone told you that 1 out of every 5-10 older adults who get the disease would die, then maybe we can begin to appreciate it's severity.  Not that younger people are free of risk either.  The latest estimates have reported that 1 out of every 100 people who get the disease will die from it.

That brings me to much of what I observe and read about in terms of younger people unafraid of the disease, not taking precautions, or engaging in risky behaviour.  Just because younger people are less likely to die, they still spread the virus and kill others.

Hopefully, everyone is safe.  I am curious to hear about your personal experiences where you are.

~ Z

Greetings everyone,

I thought I would write a quick progress update on the status of getting LN transactions up again.

I've implemented all of the fixes for the deposits and withdrawals.  Theoretically, I could re-enable now.  However, I am going to fix up some other aspects as well, which will further improve the safety of funds. 

Here is what I am doing:

• I am making user tips more robust.  Anonymous tips (via LN) now have the same funds safety checks to ensure that the intended user gets the funds.
• I am making voting more robust.  Again - I am going to ensure proper funds synchronization when a user spends funds on votes as when a user makes a withdraw.  Although this part doesn't touch the Lightning Network, I'm going to improve it anyway.  In the process, you will notice that voting will be much more ... zippy.  This improvement is both a safety and performance improvement.

Once I have these two other improvements complete and tested, I will be turning LN transactions back on.

Hello everyone,

I noticed strange activity on the ZapRead LN node.  I have stopped it for the time being.  Apologies for the inconvenience.  I will investigate but hopefully there is no issue.  

It looks like some kind of bot activity making withdraws.  

I'll follow up with an update once I sort it out.

Alex Bosworth - May 13, 2020

Announcing Lightning Multi-Loop: Upgrading Lightning Loop with Multi-Path Payments

Today we're happy to announce that the recent release of LND 0.10.0 has enabled Lightning Labs to release the first major upgrade for Lightning Loop since its beta release: multi-path Loop support. As Loop is a non-custodial service that translates Lightning off-chain funds to blockchain on-chain funds, it is specifically designed to service amounts suitable for the Blockchain that are larger and aggregate many off-chain micropayments. To scale this value up we're adding support for Loop users to leverage multiple channels in a single Loop Out to the chain. We are also raising the limit of a Loop Out from 0.042 BTC to 0.1 BTC.

Since the Loop Beta that we released in February we have also been working on some changes for Loop In. With this multi-path payments release we now have the ability to use multiple channels together to translate on-chain funds to refill your off-chain channels. And we have also added the ability to specify your preferred on-chain fee for Loop In to maximize the cost efficiency of getting your on-chain funds into Lightning.

Using multiple channels for Loop payments is an ideal use-case for the multi-path payments technology. Rebalance operations to move off-chain funds from ten channels onto the chain could previously have required at least ten separate on-chain transactions with Loop Outs or channel closes. With multi-path payments support, these same ten channel rebalances can now be achieved in one on-chain Loop Out operation.

Batching With Multi-Path Payments

As Loop and Lightning are scaling solutions designed to enable more people to get more out of the Bitcoin Blockchain and spend less in on-chain fees, our goal is to maximally aggregate our transactions when using the blockchain.

If you are already familiar with the recent MPP upgrade in LND, then you know that it allows for a single Lightning payment to take multiple paths to its destination by splitting the payment into multiple pieces and having the receiver put the pieces together on the other side. This is exactly how it works in Lightning Loop, but with an added security guarantee.

In the first version of Lightning Network multi-path payments, it is a system wherein the receiver can potentially choose to receive part of the payment, but they are simply incentivized to not do that as waiting may result in more funds received. In the case of Loop, we can do better than this because in the Loop protocol the initiator of the Loop Out is also the ultimate receiver of the payment. Even though the Loop Out server is receiving a multi-path payment that is not normally logically atomic, the client's control of the payment resolution makes this a logically atomic swap.

In our first release of multi-path support we have some deliberate limitations on the amount of funds that may be swapped. This is because we are still working on hardening the protocol and adding features that allow leveraging multi-path even more than we are today. Technically speaking there are no limits to the amount of aggregation we can achieve using this technique, ultimately unlimited numbers of channels may be used for a Loop Out or Loop In, all resulting in the same single on-chain spend to an HTLC address.

Leveraging Loop In

While people love the ability to offload received Lightning funds directly to exchanges or cold wallets with Loop Out, we are also continuing to invest our efforts in new improvements to Loop In which allows for recharging depleted Lightning channels.

Multi-path payments are especially advantageous for Loop In. In a normal usage of the Lightning Network, we'd expect that a user who has created a series of channels will in many cases eventually spend these channels down over time as they make purchases, deposit on exchanges, and use Lightning Apps.

With single-path Loop In, that user could refill a single channel to keep their channel open, but they could also simply create a new channel, and these two options would cost similar amounts of on-chain mining fees. With multi-path Lightning, we unlock the capability for the user to use all of their channels as a single balance, spending multiple channels together. And with multi-path Loop In, we unlock the capability to completely refill all of a user's channels at once with just a single on-chain HTLC.

Start Multi-Looping Today

In order to take advantage of the new Lightning Loop multi-path support, you will need to first install LND 0.10.0. This new release is now the only version of LND that is supported by the current version of the Lightning Loop reference Go client and the only version that supports multi-path payments.

The increase to a 0.10000000 BTC limit and the upgrade of LND to 0.10.0 are still just the beginning of improvements planned to allow even more bitcoins to flow over the Lightning network with minimal cost and friction. If you are interested in higher limits please email us or join our Slack where you can also chat with other users of the service and LND.

https://lightning.engineering/posts/2020-05-13-loop-mpp/

ZapRead.com has registered for the Lightning Hackathon.  Please check it out!  https://wiki.fulmo.org/wiki/Challenges_May_2020#Zapread.com

The primary challenge I've posted is an authentication challenge - using your Lightning wallet to register for ZapRead, and to log in!

Develop a C# LNURL-AUTH library which can integrate with .NET (MVC) websites.

Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-zapread

The secondary challenge I have put forward is to develop offline payments for Lightning.  Maybe a bit too ambitious?

See you there!

How is Bitcoin doing these days?  How does bitcoin today compare with Bitcoin of 2017?  It seems like a lot has changed.  So, here is a quick look I decided to put together.

SegWit

Segregated witness was activated in August 2017.  It segregates signature data from transactions into blocks past the 1Mb limit - effectively freeing room in the block for more transactions.  It also paved the way for other improvements related to future soft-forks as a way to add new features to Bitcoin without disrupting existing users or requiring everyone to update their software.  Let's look at segwit adoption:

Not as good as one would have hoped, but the trend is good.  In terms of large (i.e. in value) transactions, Segwit has become the sleight majority.  In terms of the number of transactions and block-space used, SegWit is now half of the transactions.

Blocksize

That pesky 1Mb block limit, which can't be removed without a hard fork (and associated risk/split/centralization).  How has it changed over the last 5 years?

The solid block around 2018 is when blocks were full - fees were sky-high, and we were witnessing a boom in Bitcoin.  The blockchain hit a wall.  SegWit was new.  That seemed to have resolved, and we can now see that blocksize averages of 1.3Mb are common. The blocksize could still be even higher as not everyone is using SegWit yet.

Fees

What happened to fees over time?

The fee issues leading up to 2018 is clear - but then, it seems to have settled down.  It may not stay that low if the demand for transactions goes up, but we are far from the fee issues we had in 2017 and 2018.

Lightning Network

The beta lightning network is still under development, but, it is already very useful.  If you are reading this, you've probably enjoyed a few Lightning Network transactions already.

The number of public channels and capacity seems to have reached a plateau.  A public capacity of 1000 BTC seems to be the sticky point. Unfortunately (fortunately!), due to the nature of the Lightning Network, we can't see how many transactions are going on.  How's that for privacy enhancement?  I can say that my lightning node has already conducted almost 130,000 transactions.  Yes - that's right 130K!  I think I've paid under $1 in routing fees for all of those combined.  I also open channels at 1-2 satoshi/byte, so minimal chain fees too.

If we were to have this kind of transaction capacity on the native blockchain, that would take about 52 blocks of space.  Also, remember - I am just one of now 12,000 public nodes on the network.  I might be among the most active nodes, but I hope that one can see the scaling going on here.  At even $0.01 per transaction, that would have cost $1,300 to transact on-chain, likely more.

Keep in mind this is all on a measly 1Mb blockchain.

Summary

I think that Bitcoin is in a pretty good place.  There are still things to work on (i.e. keeping fees low), but the future is bright.  We are not in a corner, and there are multiple exciting developments in the works.  The change that has me most excited is BIPs 340, 341, and 342.  These Bitcoin Improvement Proposals add (through soft-fork) Schnorr Signatures, Taproot, and Tapscript.  I should do a future post to explain what this gives us in more detail - but I'll say now that it gets me really excited for the future of Bitcoin.  I'm talking about privacy, scaling, safety, and powerful smart contracts.

* Note that nowhere in this post did I make any mention of market prices.