Soft-forks are not enforced on the older parts of the chain. Only in blocks from two weeks after 95% of the hash-power had signaled their intent to enforce (counted over a 2016 block interval after the change start-time).

For prior soft-forks, like strictder, there are many historical violations before where it was enforced. It does not make the chain invalid, only violations after the point where the new rule's enforcement begins would do so.

"100%" of them. The above posts are confusing old single party unidirectional payment channels; more powerful designs have been known for something like 5 years, the most sophisticated with are the bidirectional payment mesh systems we call lightning today. No reoccurring usage is required to make use of them, though they're super efficient for that case.

John Ratcliff wrote a nice informal discussion about what bidirectional payment channel networks are:  https://letstalkbitcoin.com/blog/post/the-lightning-network-elidhdicacs

It would be valid, of course. Perhaps you should consider posting less and studying more? -- not trying to insult, but without the basics you're wasting people's time.

Blocks are always full. When they're not a million bytes, they're less because a miner chose to limit the capacity further, but to whatever capacity they were allowed they're full. There are spam generators that generate a constant flood of minimal fee-rate transactions constantly 24/7... a node with all anti-spam defeated and no mempool limit quickly ends up with hundreds of megabytes of transactions.

This isn't a problem, it's how the system works... and it is unavoidable in a decentralized system ---  imagine instead that there were no limits at all (not in the consensus rules, not by miner collusion)-- that would be the necessary criteria for blocks to not be "full" and in that world a single kid with a while loop could throw hundreds of gigabytes of data into blocks and rapidly DOS the whole system into the ground.

When you get fed hype around "full" blocks, you're being fed a fake emergency narrative.

The blocksize limit protects against that, but it's preferable to use the least amount possible, since even the limit is high enough to make running nodes burdensome; better to spend user's limited tolerance on actual Bitcoin transactions.

Especially when you realize that people connected to classic are demanding not "75% of users" or "75% of bitcoin ownership" but 75% hashpower, the last of which could just be a couple people.

That isn't true. A long time ago they were done with hashrate thresholds that low and it was problematic. More recent ones have been 95% hashrate.

That is also not true. You could create some kind of colored coin and try to convince people to accept it as "bitcoin" even without any soft-fork, but no soft-fork can increase the supply of actual Bitcoins.

The Bitcoin consensus protocol allows creating and sending transactions involving no bitcoins what-so-ever.

Bitcoin Core currently regards such transactions as spam and will not relay them.

This is the basis by which proponents of various parasitic consensus systems (their term not mine) have argued that their new currency would completely displace Bitcoin even while using the Bitcoin network.

I would encourage you to read what I actually write. I said nothing of illegal opcodes, and for good reason.

The primary established mechanism for safe softforks is the reserved script NOPs (which will not be relayed or mined by unmodified software today), the secondary one is transaction versions. They are reserved for explicitly this purpose. The reason for this ranking is that version is global to all inputs and outputs in a transaction; which creates unwelcome tying-- one should be able to spend and create mixtures of coins under different rule sets. For changes that happen outside script, however, version is still available for use.

For segwit the primary mechanism will be segwit witness script versions... which are more clear and flexible than the reserved NOPs.

What you're saying is equivalent to "in theory there could exist some totally busted software that just make up random crap when alice punched in an address, thereby burning the coins"-- this is true, but it's unrelated to segwit.

The recipients address specifies the scriptPubkey that they must be paid-to in order to be paid.  If you don't pay to what they've specified, you haven't paid a party.  In the OP's example, Bob would have provided an ordinary address-- the same as he provides today, perhaps-- and the payment would work like normal.

How the txin scripts work and txout scripts work are completely orthogonal.  Someone can spend segwit coins and the receiver doesn't care, it doesn't change their operation; beyond the fact that their older client will see the payment as a non-standard transaction so their non-upgraded wallet will not display it until it confirms.

Something being less subject to defaults in practice is not equivalent to a system in which defaults are not possible.

Lightning is lightning, it isn't anything else; trying to reason about word pattern matching obfuscates understanding rather than enlightens. If what someone disliked about a weeblix system was that it subjected users to flimdar, then it would be pretty misleading to suggest people wouldn't want some feature that made a system more weeblix like if it didn't expose them at all to flimdar, even if it was otherwise weeblix like.   In this case, I don't even think it's fair to say that lightning is "like" netting, as all transactions in it are ordinary bitcoin transactions ready for transmission to the network-- you just save fees by holding off sending them and having opportunities to revise them. More like writing someone a check, then asking them to rip it up and giving them a new one later in the day when you make another transaction with them-- they could settle it at any time, but save bank interactions if they hold off. Netting would be like writing the check at the end of the week. And in Lightning, unlike the check, the risk is eliminated because of Bitcoin magic.

Today the vast-vast majority of transactions exchanging Bitcoin value never show up in the blockchain-- mostly due to systems with significant counterparty risk, indeed. So, some users perform netting on top of Bitcoin to lower their costs and greatly improve their transaction speeds. Is Bitcoin a netting system? No.  Bitcoin is p2p electronic cash, which periodically settles transactions written by users (which may be revised on the fly prior to settlement). Lightning uses the smart contracting system in Bitcoin to allow that ability to revise pre-settlement for transitive flows of funds without a counterparty risk for funds loss, and not just for single hops.

Lightning is not a netting system, -- as a clear evidence for that netting universally involves counterparty risk of loss and lightning does not. But if you wanted to talk in terms of netting you perhaps should have said that.

Conspiracy theorize all you like, even if it were all true it wouldn't excuse making incorrect statements about Classic's plans...

This is Bitcoin "Classic"'s proposal:
The main developers of classic previously were pushing an effectively unlimited exponentially growing scheme. They generally reject the notion of any blocksize limit at all.

It isn't just a new name, the channels are bidirectional; which radically improves their utility.

Have you been introduced to the concept of "blocks"? (sorry, I really don't intend this to be mocking sounding, but I'm not finding a better way to put it).  What you described is _exactly_ how Bitcoin works.

Huh? I do. What ties to what banks are you talking about?

I do. What is a "LN hub"?  If you're talking about lightning, every lightning transaction is a "real bitcoin ledger transaction" just most are hopefully superseded before they hit the blockchain, without degrading their security. If this seems impossible to you should checkout cut-through transactions as a parallel technology that might open your eyes.

In my vision of lightning there isn't much in the way of hubs, but a mesh of users. If I wanted to build a hub I'd build a chaumanian cash bank. Payment channels were originally proposed by Bitcoin's creator, and the Bitcoin transaction format has specific affordances to support them (e.g. sequence numbers).

Consider the question from the survey:

What is "Bitcoin" being referred to there?  Is it referring to the Bitcoin Currency? Or the P2P network? or the blockchain itself? current Bitcoin companies?

What is a "settlement system" which is exclusive with"cash system"?  The definition of a settlement system is a system that delivers money in exchange for the fulfillment of a contract. This is the technical definition of the Bitcoin blockchain. What is a "cash system"?-- The bitcoin currency is cash (although cash with some fungibility problems); if it weren't the blockchain couldn't be a settlement system (since it wouldn't be a system that delivered money for fulfillment of agreements); and none of these two are incompatible with Bitcoin being a store of wealth.

There is a common misunderstanding of what settlement means-- to suggest that its somehow not for personal use, and also suggesting that these options are exclusive. They aren't. And one of them, except "a store of wealth", even speak that strongly to the blocksize:

One could have a "peer-to-peer electronic cash/settlement system" that was highly regulated, censored, and had a politically determined and/or unstable monetary policy. But it's hard to imagine something that would be a good "store of wealth (digital gold)" that wasn't a strongly autonomous and permissionless bearer instrument with a strongly fixed monetary policy (criteria which might implicate the block size in both directions).


Maybe I was expecting too much of the poll.

It certainly seems to have nothing to do with technical discussion.

The prediction is it wouldn't.

I mean, if you're using a third party API then at any point they could make you add an argument "moon moon fish moon"... but there is no reason for them to do that; likewise for segwit.

No, it's way faster because the initial startup tests are truncated when the cache is too small. (Because they undo a bunch of blocks in memory and redo them... they need enough memory to hold that intermediate state)