A short video I made to explain the "so what" of taproot in 10 minutes.  If you like it, please subscribe to my new youtube channel :)

Interesting discussion between Elon and Vlad (RobinHood CEO)

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/