Yes, I know. It wouldn't be any different if:

1. hardcoded LOT=false 0.21.1 is released, miners stalled until timeout, LOT=true is released
2. Flag day is set for August 2022 (new proposal vaunted today on bitcoin-dev ml)

people would still download the software without understanding they were implicitly supporting activation of a softfork.

I wrote exactly that: people often don't know what they're doing when they upgrade. They also don't know what they're doing when they fail to change an option.

I could understand this "consent" argument of yours if someone had a credible argument about how taproot/schnorr was going to have a negative effect on people that won't even use it, but there are none. Like with much of Bitcoin (and tech in general), many people will use Taproot without even knowing they are, because they're not interested in the details.

right, that's the argument here: it shouldn't be available as an option, I'd only disagree that defaulting to "yes" is forcing anything on anyone



If dangerously low numbers of people running nodes upgrade to 0.21.1, then miners/pools won't follow the fork either.

Why have layers of opting-in to complicate the situation? People ought to be aware of the Taproot soft fork, and that running Bitcoin 0.21.1 will contribute to activating it. How is that any different to adding an extra option?

• If LOT is an option, some people won't set it, unaware that it's there (or don't understand what it does)
• If 0.21.1 is hardcoded to either LOT=false or LOT=true, some people won't upgrade, unaware of the implications (or don't understand them)

What's the difference? As a way to choose your preference for LOT, there is no difference. As a way of making the network safer right before the fork is activated, there's a big difference.


 

Money didn't exist thousands of years ago. The whole concept of currencies/money developed from people bartering with commodities. One commodity tended to become the most popular to barter with, for a variety of reasons. Traders started to use a different word to describe that most-popular bartering item, and so we ended up with something called "money".

FYI, lukejr regrets adding LOT to BIP 8

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html

background: link to Taproot Proposal thread


tl;dr, luke is writing code for activating soft forks in Bitcoin, and he thinks it was a mistake to make an option for the new soft fork code for Taproot to lock-in automatically (this happens if miners don't signal to activate before the fork's activation time limit is over.)

I agree. If there's a mix of nodes signalling to activate (LOT=true) and not signalling (LOT=false), a wide variety of problems can occur, especially if miners activate without paying attention to what other nodes are signalling. For that reason, miners might take the safe option of _not_ activating, assuming they don't want chaos. The other way to look at it is that some miners might like some temporary chaos, as it gives them or any friends of theirs with spare fiat to buy any market dip caused by said chaos.

The potential for chaos if people can choose which LOT they want is pretty high. It's both possible, and possible to exploit. So, I agree with luke. Stability, of every facet, should be the paramount concern.


The subtext to most arguments revolving around this issue is:

• 1. let people decide for themselves
• 2. we must be sure that they know and understand what they have chosen

Point 1 is easy. Point 2 is hard, and probably not realistic.

But I disagree with the idea that pushing out LOT=true with Bitcoin 0.21.1 is somehow forcing users into something they didn't want.


Everyone is responsible for understanding what's in the Bitcoin software they run (and for all software they run). Significant numbers of people don't pay any attention though, and that's unlikely to change much before or immediately after Bitcoin 0.21.1 is released (although I'd argue that the trend for being more conscious of "what's in my software" is increasing).

---

So the decision seems easy to me:

• Release Bitcoin 0.21.1 with LOT=true, no option to configure it
• Running 0.21.1 or not becomes the choice as to whether the soft fork activates

This way, all potential chain forking chaos is avoided, and most of the drama will be neutralized.

Don't like Taproot? Then don't run Bitcoin 0.21.1, and you can try to convince others to do the same. It's simple to understand, and if people don't understand it, then making the options more complicated is a perfect recipe for making the situation much, much worse.


Thread rules: No trolling, no trolls

it seems Nigerian bitcoiners disagree, lol

and this cuts right to the heart of the issue: if regular people choose a different money system, there really isn't anything the so-called authorities can do about it. The legitimacy of one money over another is purely about what perspective you look from, and the Nigerian central bank isn't happy which direction normal people are turning their heads


it's true that it's _potential_ right now

Lightning is now usable and reliable, which was the first challenge. It still needs more development, some of which just needs work on the LN protocol itself (anchor commitments, various advanced routing techniques), but some requires a softfork to Bitcoin itself (taproot is needed for scriptless scripts...which is needed for discrete log contracts; some way to get "empty inputs" is needed for eltoo... which is needed for channel factories...)

It's an exaggeration to say that the Lightning ux isn't smooth enough yet (e.g. breez wallet etc), but that doesn't mean it couldn't be made smoother (and cheaper, and with more network-level features)

highly amusing

we've got past the "it's a scam" stage, and now we're onto the "...but banks are better" stage


the mere fact that any status holder feels the need to defend banks is simply evidence that Bitcoin is gaining traction. For cross-border payments from countries with weak/dying central bank currencies, Bitcoin has already replaced banks

Serious traders will be the first to use Lightning as part of their typical usage of Bitcoin. I'm sure these types are already trying to avoid the high fees during market frenzies, but being confident you can _reliably_ use Lightning to circumvent the mempool will push them towards consituting the main userbase of LN. There's signs of that happening already, Bitfinex reported significant use of their Lightning deposit feature (but apparently not Lightning withdrawals) in the recent run up to $50,000

Ironically, new (not serious) traders will probably do the same, but only once they actually understand that the option is available. It's fairly realistic to imagine this as a recommended workflow:

• New user sends fiat to exchange, buys BTC
• Withdraws to Lightning wallet

If the offline channel maintenance service of the Lightning wallet in question cannot keep the channel from closing, the user's gonna wonder why they tried. That's the initial challenge for these wallet providers, and it depends on the incentives and health of the Lightning network holding up, really. From my experience, it's something like 90-95% reliable right now, which is enough for these experienced traders, but perhaps not enough for newbies to not feel a little burned.

Put simply...

Either:

• Miners activate the fork. This happens when a certain % of miners are making blocks with a special "taproot ready" flag embedded in their mined blocks. This % of blocks must continue for ~2 weeks (for 2016 blocks)
• Users activate the fork. This happens when the timeframe for activating the fork expires

It's a little more complicated than though. Not much.

As of yet, the % for triggering the 2016 block lock-in stage hasn't been decided. Suggested figures are 90% or 95% of blocks (95% was used for some recent fork activations). The overall timeframe is also not exactly decided, but 1 year (measured in blocks...) seems to be a popular suggestion.

ok, so it's easy, remove the "lottery"

Bitcoin can run in testing mode, without block mining that increases in energy consumption, exactly what these commenters want, right? Anyone can set up Bitcoin this way to create a completely new currency, sans "lottery"


and when this new Greencoin has been running a little while, people using it will be coming back to the experts asking "we have various problems, how to solve?"

in the past (several years back), there was a bug in Bitcoin Core related to the Socks5 proxy options... I forget the details, but using the "separate socks proxy for Tor connections" was causing a problem IIRC

if you're only connecting via Tor, then using the separate Tor-only socks proxy isn't necessary, you can set only the socks proxy and it will work fine. The separate socks proxy for Tor-only is only necessary if you are running 2 proxies simultaneously, one for for Tor and another for a proxy to some other alternate network routing. I expect most people are only using a Tor proxy as their alternate (or only) network, so the second Tor-only setting is not needed.

In future (i.e. probably Bitcoin 22.0), using both proxy settings may become more common, as I2P support is coming in that release. I think the CJDNS protocol is already supported in 0.21.0, as all it requires is already in the new address format that comes with Bitcoin 0.21.0, not 100% sure on that however

...quick confirmation: tried 0.21.0 with Armory 0.96.5, works entirely as before

It's further proof that this is (and always was) a fascist system we _all_ live under: the central bank gangsters know their money is worse, it's designed to control people, and no-one will choose it freely.

1. BIP8 uses blockheight, as opposed to timestamp. This is so that the fork can still go ahead if:

• an activation is at the "locked-in" stage (i.e. block signalling is above the threshold)
• ...but the _overall_ hashrate is falling (i.e. the necessary 2016 blocks of lock-in won't occur before the timestamp when the 12 month activation period expires)

BIP8 solves that problem by not using 12 timestamped months, but 12 months of blocks (which comes with a different trade-off: it's unlikely to be 12 actual months, and for the taproot softfork, will likely be faster, due to continuing hashrate growth). The 12 months part is just a convention, it could've been more or less (and may be in future), I think 12 was chosen simply because the segwit and CSV softforks also aloted 12 months.

2. BIP8 has a "lock-in on timeout" parameter

This means that the fork activates regardless of miner signalling level at the point the activation period expires (12 months in this case).


The continuing discussion on activation for the taproot fork revolves around whether Bitcoin 0.21.1 should be released with auto lock-in (or "LOT") set as true or false, but also whether LOT can be set as user configurable (like an enforcing version of people putting "uasf" in their user agent string during segwit activation). IMO, 0.21.1 should be shipped with LOT=true, but I understand the arguments against also. At the least, it should be possible to set in the config file.

not sure if you're referring directly to this spokesman's physical stature, but it applies: Agustin Carsten is literally shaped like an oversized football. Symbolically, it's quite apt (and a "PR" disaster); the man looks like a dangerously fat cat

FWIW, I've been using 0.20.1 with Armory 0.96.5, all is well.

I will try 0.21.0 sometime soon, I didn't notice anything in the release notes that ought to break interoperability, but I always have backed up data regardless.

The opposition is understandable; without the ability to control the monetary system, or to control the money of people living in this so-called "India", the gangsters who are trying to hold their racket together are afraid that "India" will cease to exist.

I think they (our aforementioned gangsters) may become angry (and violent) as a consequence, but in the end, they will fail. And the people will be freed (and this may not be as wonderful as it sounds, at least not initially)

I wouldn't choose exFat, but not sure if it's actually susceptible to data corruption. It's just that you can likely get something more reliable (ZFS or btrfs), or simply with more features/security (ext4)


I think people initially chose LND because it was pre-compiled, and it had more features. The features gap has largely closed, and c-lightning is now available pre-compiled too

I chose c-lightning because they went for a lightweight modular design (and because they had a veteran Linux dev running the project). The LND team seemed to work very fast (easier when writing software with golang, or so I hear), but make alot of mistakes. Don't know to what extent they're still like that, not been keeping up with it

prove it

https://blog.okcoin.com/2021/01/22/okcoin-integrates-lightning-network-for-99-lower-fees-and-near-instant-transaction-for-off-chain-deposits-withdrawals/

rollout in Q1 this year apparently

So now exchanges supporting LN are:

• Some private US one of which I forgot the name
• Bitfinex
• FixedFloat (crypto only)
• Kraken (soon^TM)
• OKCoin (sooner than Kraken)

I don't mean to gloat, but there appears to be an accelerating number of exchanges offering (or preparing) Lightning, as I predicted they would. Well, maybe I am gloating slightly