My understand is limited, but from what I've gleamed, the lightning network is the protocol, and for it to be successful, apps and other systems will need to be built on top of it.

So is there a plan of how it will play out?

We're at the live beta testing stage now of the lightning network protocol, however, there is no consumer level software for the network yet.

Is the next step for developers to create lightning network apps for businesses and consumers? If so, who's creating these apps? Is the core team working on an implementation of an app similar to bitcoin-qt?

I know that the idea of change addresses were there to give some measure of privacy to the user, but is that really necessary for it to be the default? With the growth of the UTXO causing some of the major hurdles in bitcoin growth, could it be changed to an opt in privacy setting?

I know at the moment coin control is available, but it's hidden behind the advanced settings and is not the default. Privacy is the default, which I sympathise with, but I would ask is it worth it when bitcoin isn't really private anyway? Would it be worthwhile putting it in reverse? Making new change addresses as the opt-in part? And returning change to the original address the default?

Perhaps it won't make a difference because most txs are by exchanges and they wouldn't alter their method of tx creation, perhaps this this isn't a good idea because of some other reason... I'm no genius on this.

I've searched but haven't really seen it floated before, anyone got an input?

For example, if I run an old pre-segwit node, can I verify a traditional non-segwit tx I receive if it's outputs come from segwit txs?

My understanding is that if a non-segwit node looks at a block with segwit txs, it cannot verify those segwit txs because the witness data is not recognised by the non-segwit node. So when it moves down the chain, how does it verify a new tx that is reliant on past segwit txs?

In a quick mock up:


* ADDRESS 0 > traditional tx output > ADDRESS 1

* ADDRESS 1 > segwit tx output > ADDRESS 2

* ADDRESS 2 > traditional tx output > ADDRESS 3

* ADDRESS 3 > traditional tx output > ADDRESS 4

A segwit node can verify all of the above txs. What happens to a old pre-segwit node if it controls ADDRESS 4? Can it verify that the coins are truly valid? Or does it just assume they are?

[The alert system had not lost it's usefulness at all.]

I've been reading over a few bits of history (see sources below), and the removal of the alert system has bothered me quite a bit. It was stated here⁴ that:

The Alert system has also lost its usefulness. It is no longer necessary to use it to inform users about problematic network events as users can easily get their information from any major Bitcoin news outlet.

The other justification¹ was that the

Alert Key (was) Compromised

This is related to the fact that there was a single key for the alert system, which was handed out to a number of core devs, and over the years people left the project. Thus it was thought that this was a risk (in that people could send alerts without vetting) that might affect users.

I wanted to talk about this because although I agree with the latter (I don't believe that you can leave the key for an alert system in the hands of so many people), I disagree with the former. The alert system had not lost it's usefulness at all.

The justification was that communication could be done to the community through:

• forums
• reddit
• slack
• github
• an opt in mailing list

IMO this is an incredibly short sighted point of view, and one that is now biting us in the butt. One of the major bottlenecks to getting BIPs through has been the difficulty in communicating to clients and getting clients updated to prevent problems.

An alert system is incredibly useful in the event of a necessary HF to implement proposed BIPs. This has been a HUGE issue in the community and it could have been avoided had an alert system of some kind been kept in place/added.

An alert system completely solves the issue of users forgoing critical updates to their clients, which allows for faster progress in development.

I think this is something that needs to be discussed and pushed forward perhaps in the future. Some may think it is too late to do something now, but while the best time for the alert system was yesterday, the second best time is today.

Example of the old alert system:


Sources:

1. Alert System - Bitcoin Wiki -(https://en.bitcoin.it/wiki/Alert_system)
2. Github alert system removal 1 - (https://github.com/bitcoin/bitcoin/pull/6260)
3. Github alert system removal 2 - (https://github.com/bitcoin/bitcoin/pull/7692)
4. Bitcoin.org announcement of removal - (https://bitcoin.org/en/alert/2016-11-01-alert-retirement)