DDoS is not “activism”.  It is vigilante censorship via Internet arson.  Its ultimate result is to increase the centralization of the Internet under the power of huge “anti-DDoS” corporations who are part of the mass-surveillance infrastructure—thus destroying both privacy and freedom of speech in one blow.

Cloudflare loves scum like you; you are the enforcers who shove sites under their control.  Sites such as bitcointalk.org.

I hope you die of cancer.

Objectively, “neurotypical” users will be helped by an error correcting code which permits software to point out to them where they are likely to have made a mistake.  That alone makes worthwhile a switch away from addresses checksummed with truncated-double-SHA256, in my opinion.  Also, I can personally attest that a “neurotypical” user has serious difficulties with mixed-case pseudorandom strings.  That’s the sort of design which leaves me cursing at things made more for the convenience of computers, than for the safety and sanity of humans—cursing whilst I back up and try the damn thing again, in some use cases on try 3/3.

I have some pie-in-the-sky, 1/65536th-baked ideas about crossing identity-based encryption with privacy-preserving payment codes and (waves hands) to neuter the central authority.  Someday....  I think everybody serious in this space has dreams of “squaring the triangle”; at least it’s more stylish than trying to build perpetual motion machines or recursive compressors.

As for what you said about developers being “likely to prioritize having things fit neatly into binaries”—yes, I get it.  I hope you caught my self-directed sarcasm about ASCII offsets in a base32 alphabet.  Well, I think I can squeeze in a lookup table.  No, better yet:  I’ll grab sipa’s code, review it, and call it a day.  That way, the wetware gets its confusables carefully arranged for maximal error detection.  But for revenge, I shall still get my jollies by changing case with bit-twiddling 0x20, etc. instead of calling the appropriate C library functions.  Hah!  The warm, squishy anthropoid lusers will never even know what I just did there.

Bech32 is a huge UX improvement.  Most of BIP 173’s implicit motives and explicit rationales cater to human needs.  I have no doubt that Bech32 will make Bitcoin addresses easier (or at least, less painful) for the overwhelming majority of “neurotypical” users—especially for the legions of future newbies who have not been biased through being emotionally accustomed to old-style addresses.  As such, I don’t get your comment about altcoins.  Bitcoin leads the way here, again.

Close.  You can send and receive with a party with whom you’ve established a channel.  Well, what if you’re connected to Alice, and you want to send money to Bob?  If Alice has a channel open with Bob, then you can have Alice “route” your payment for a small fee—essentially letting Alice be a mini-Visa network for you.  These routes can be extended with multiple hops, potentially (but not necessarily) passing through large hubs; did you ever play “six degrees” style games?  Developers with a focus on privacy have also been working on onion-routing Lightning transactions; think of a Tor which routes money, instead of routing stream sockets.  (PSA: This message is posted through Tor.)

Conceptually, roughly, the reason why the system can’t be gamed is that you send Lightning payments by providing your counterparty with sufficient information to slam the channel closed with the updated balance, and claim all their money on-chain.  Cheaters can’t do much mischief, in those conditions.  That’s a sketch of the system’s general shape.  The Lightning whitepaper (PDF) provides a good technical overview of how it really works under the hood.


On-chain transactions also happen when closing the channel; that’s how final balances are settled on-chain.

You ask an excellent question about simulations.  I would appreciate more information about that, myself.

A related question is of how many global users Lightning could handle, and what tps it could reach, with the current capacity of the blockchain.  Back of the envelope, if on average a channel handles x LN transactions, and an on-chain block can hold y transactions, then the upper bound of Lightning capacity (ignoring other Bitcoin use) is about x*y/2 transactions per average 10-minute Bitcoin block.  I recently came across a neat little chart giving some numbers here; sorry, I can’t seem to find it at the moment.  The numbers looked fairly impressive, even given my desire to see orders-of-magnitude scaling of the Bitcoin ecosystem’s transactional capacity.

In that regard, I look at Lightning as a huge force multiplier for any further incremental on-chain scaling improvements.  Of course, I also hope that Lightning itself will see further scaling improvements as it matures.  If it gives big, then I’ll want bigger—well, one step at a time!


Well, spurious opening and closing of channels would simply be a matter of spamming the blockchain with spurious transactions.  We have that problem already.  I don’t immediately see how Lightning itself could be problematically spammed, given that it’s relatively low and symmetric in resource use (spam needs highly asymmetric costs), and channel participation is by voluntary mutual agreement; but I do not yet have sufficient Lightning expertise to say authoritatively that it couldn’t happen somehow.  Another interesting question I shall need to think about.  Any takers here?

Apropos:  Bitcoin mining is NP-hard (or rather, transaction selection is).  The upshot is that it doesn’t get solved optimally, at least from a theoretical perspective.  In practice, “good enough” is good enough:  Fill your knapsack mostly full of mostly the best stuff, and start hashing.  The race is on, and time is critical!

There are all sorts of prickly points around the subtle art of selecting transactions for inclusion in a block.  When making changes to Bitcoin, careful engineering work can be required to at least not make it harder.


Please be advised that this is a forum for technical discussion, titled “Development & Technical Discussion”.  For basic questions about Bitcoin, go to “Beginners & Help”.  For technical support appertaining to “Bitcoin Core, nodes, the Bitcoin network, transactions, and addresses”, go to “Bitcoin Technical Support”.  For education needed by “every1”, see alt.english.usage.

Ouch.  I jumped into the middle, replying to a user who was making the same blatantly incorrect assertions about Segwit in many different threads simultaneously.  I somehow missed that this thread started with talk of “the flippening”, that link we’ve all seen, and blah blah blah about Blockstream.  Oops.  I should be more careful.

Well, OP here got useful replies; and he seems to have responded graciously enough.  For every troll, shill, and professional liar hawking a tall tale, there are n newbies being sincerely misled—for an uncomfortably large value of n.  Your advice to them is sound, savushkinTA; but how is a newbie to know that he’s tumbling down a rabbit hole, one wherein all the rabbits have been killed and eaten by poisonous snakes?

LN transactions do not “converge within a block and get settled blockchain”.  No record of them ever reaches the blockchain.

The only LN use of the blockchain is channel maintenance transactions, “people opening and closing LN channels” as you said.

Imagine that you and I make an agreement to trade between each other, and track our trades in a private ledger.  We create an entry in a global public ledger, devoting funds to our private ledger transactions.  When we’re done and we want to settle accounts, we record our respective final balances from our private ledger in the global public ledger.  All else in the private ledger stays there, nowhere else.

Of course here, our “private ledger” is magical.  It provides each of us a unilateral recourse to force the current balances into the global ledger, in case of cheating; so there is no counterparty risk.

By an “objective reason”, I meant something along the lines of:  “Truncated 32 bits of double-SHA256 is a bad choice for a checksum, because it has no error correction, relatively poor error detection, terrible performance (time cost)—overall, it’s a choice much inferior to a simple CRC-32.  Its only advantage here is that it’s a hammer you already have in your toolbox; the disadvantage thus is that everything starts to look like a nail.”  A significant technical flaw would certainly warrant some discussion.


True, that’s a particularly awful pair of confusables.  I’ve been thinking on what you said about that.  Fortunately, “1” (one) is not part of the Bech32 base32 alphabet and is never valid in the data part; therefore, I think perhaps there may be a special corner-case for error correction:  When the character “1” (one) is encountered in an invalid Bech32 string, in a position where substituting an “l” (ell) would produce a fully valid Bech32 string including a valid checksum (and only a single such substitution is required), then perhaps automatic error correction (or at least suggestion) should occur notwithstanding the specification’s statement that “implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.”

Of course, as you said in your original post, I would not expect users to remember (or even know) the distinction between a “separator” and a “‘data part’ base32 alphabet character”.  My idea here is that maybe implementers should consider autocorrecting this one specific case.  A similar case may apply where no separator at all is encountered, and a single substitution of a “1” (one) for an “l” (ell) would produce a fully valid Bech32 string.

Thoughts from devs/implementers/UX experts?  Should I perhaps mull a concise way to state this in a revision to BIP 173, or would that just be opening a can of worms with (infinitesimal) potential for sending funds to nonexistent addresses?

So as for ells and ones.

Obviously, in this scenario, there are some matters of taste.  I myself am accustomed to base32 identifiers, so it’s easy for me to take to another one.  I suppose that someday, those old-style addresses will be beyond the realm of nostalgia—more like museum-quality antiques; albeit functional ones, for the people with coins in really long-term cold storage.

For my part, I see Bech32 as a positive sign that Bitcoin continues to lead with innovation in a field it created, that of “cryptocurrencies”.  Bech32 already has some uptake amongst altcoins, at least those with a Segwit implementation.

I hope that Bech32 works out for you in your real-world usage, however you find most comfortable to case it.


Hey, I’ll admit to that, too!

This user copypasted my post, on the next post right underneath it!  Looks like a bot, an exceptionally stupid bot:


My post:


I will hit the “Report to moderator” button also, of course.  (I have reported >100 posts in the past few weeks, with 100% accuracy.)  I post here to request nuking from orbit.

Aside, I wish I had discovered this thread before.  I reported a number of copypastes, with links to websites copied.  I don’t know if those accounts were banned, as they should have been.

Thanks to mods for their efforts shovelling garbage out of a landfill with a spoon, as the garbage trucks continue to arrive.

casascius, with all due respect, I don’t see any argument here other than sentimental attachment to the appearance of old-style addresses, plus a few relatively minor quibbles about confusable characters.

I will address the latter first, since it is a technical issue.  Any selection of characters for such an application will always involve tradeoffs of excluding worse confusable pairs, whilst regrettably tolerating some less confusable pairs.  Of course, making that distinction cannot be what I’d call an exact science.  BIP 173 set forth its rationale on this point; do you have any objective reason to contradict the research it cites?

As for the “flavor”, as you put it, I don’t mean to be derogatory.  You yourself characterize it as a matter of “affection”.  But it’s just that.

A colourable argument might be here interjected on grounds of marketing.  But really, from the coldest marketing perspective, how many actual Bitcoin users do you propose to be attracted by the “look” of the addresses?  You speak rather derisively of “a whole legion of Bitcoiners who scan URI-less QR codes at PAL resolution with VHS cameras and 6502 processors are leading the charge to change Bitcoin so they never have to upgrade past the pre-Internet as they send their Bitcoins off a 64K floppy disk.”  But I think here, you have it backwards:  Persons fixated on the look of the address will be a marginal minority, frankly stuck in the past and resistant to technological improvements.  I suspect that unfortunately, most Bitcoin users care neither about the look of the address, nor about its technical functionality—in other words, they agree neither with you nor with me.  They scan QR codes, they think about money, and as most people generally, they contentedly chew their cud in the Coinbase corral.  The form and function of Bitcoin addresses is really a non-issue here.  I’m more worried about how many don’t care about decentralization, fungibility, permissionlessness, privacy—freedom.

I will meet you halfway in positing that the human-readable prefix “btc” would be better than “bc”, at the expense of an extra character which transmits no data.  The string “btc1” now carries some rotten baggage; but Bech32 antedates that wretched idiocy and will long outlive it, just as the same applies with its use of the “BCH” error detection algorithm which is its namesake.  “btc1” with the separator also seems an homage to the old-style P2PKH addresses; indeed, I have a tiny suspicion that the reasons for choosing “1” as a separator were not wholly technical.  That warms my heart, and might even mollify you a bit.  I suppose “bc1” sort of does that, too; and hey, it saves a character!  Of course, this is an issue only with the specification of Bech32 addresses for Bitcoin, and not with the Bech32 format itself.

Returning to technical issues:

I think you far underestimate the difficulties caused by mixed case, especially for persons accustomed to non-Latin writing systems—or for anybody with fingers for typing, plus a labile human central nervous system which cannot reliably process and transmit patternless pseudorandom data at all.  The human brain finds it easy to follow the patterns natural-language capitalization rules; to add capitalization to gibberish only adds the dimension of an extra variable to keep on the squishy wetware mental stack.  For your anecdote of being just fine and dandy with the mixed case, I will raise you my anecdote that I hate it, I can’t handle it—I find it absurdly frustrating and error-prone.  Surely an expert in human-computer interaction will weigh in here; do you wish to place bets (gentlemen’s wager) on whose side that evaluation will support?

Satoshi was a genius.  But let’s admit it:  He had a few quirks.  The propensity to use (truncated double-)SHA256 where inappropriate is one of them; and Bech32’s change of checksum removes one of those niggling little flaws which always irritated me amidst such an ingenious creation.  And that base58 you so adore—well, I love it not; and I doubt I’m alone there.  I think there are exactly three people in the world who are enamoured of base58 for use in a binary-to-ASCII encoding system; and now we have enumerated two of them, you and Satoshi.

I’ll admit, as a C programmer, I am a tiny bit annoyed by the Bech32 choice of alphabet.  It’s not in ASCII order!  The stupendous inconvenience of a lookup table is required for decoding, rather than simple arithmetic from offsets as in RFC4648 base32 alphabet!  Horrors!  Well, I do suppose that I, too, can be annoyed by Bech32’s kindly consideration of squishy humans and their errors.  I recognize that regrettably, I have just made what is perhaps overall the single most myopic anti-Bech32 argument ever yet proposed.

I will here “truncate” this flow of words, for I needn’t here (double-SHA256) rehash the rationale of Bech32 design choices.  BIP 173 already did that, and did so at least adequately to persuade me.  Well, it did more than that:  The Bech32 format is so superior technically that it made me realize, on a deeply personal level, just how excited I can be made by an address format.[1]  To be fair, I there mirror your pained nostalgia for the old format.  Also to be fair, I admit that I am odd.

Please give Bech32 a chance to grow on you a bit.  If you keep an open mind and try it for awhile without bias, I think it will win you over.

---

1. My regards to Pieter Wuille and Greg Maxwell:  I can tell that an excruciatingly detailed thought process about Bitcoin address formats went into that bit of engineering.  Somebody stayed up in the dark wee hours, pondering the philosophy of Bitcoin address formats.  Somebody aspired to consummate perfection in the art of Bitcoin address formats.  Well, you are probably also “odd”.  Coming from me, take that as a compliment.

You’re welcome, and thanks for the kind words!  May I suggest you try running a node on your own hardware, in your physical possession.  Core has made great effort to keep requirements accessible; no big server or datacentre backbone connection is required.  Your keys, your hardware, your security, fully decentralized and in your control.  It all just fits together.

Peaceful holidays likewise.

Aside, the mempool minimum fee is a per-node rule, not a consensus rule.  (Of course, most will go with the default.)  That makes sense, because selection amongst consensus-valid transactions is in the discretion of miners; and:


Hmmm; compare and contrast the node’s view of data it has received without any attempt at Byzantine fault-tolerant ordering, and Satoshi’s decentralized BFT database in action:


Excellent point, for obtaining a proper perspective in this particular discussion.


That’s because corporate and government mis-information services consist of misinformation professionals.  Also, disinformation professionals—a subtle distinction in the field of mass-scale lying.

Because Segwit removes signatures from the blockchain!!  Bitcoin Jesus told me so, in a vision.

(There is a problem with ir.hn having spread this garbage across multiple threads, then pretty much completely ignored the substance of all intelligent responses.  P.S., thanks for your intelligent response.)

---

Segwit sinner, dare ye blaspheme Bitcoin Jesus?  If you squint at it hard enough, you can see a 666 in the Segwit logo.  It is hidden and double-crossed inside itself within an ancient Satanic symbol called the Iron Knot of Thermopylae:


And if you play the Segwit jingle backwards, you can hear it say, “Hail Satan!”

The number 51 is also clearly a reference to Area 51.  If Segwit is a 51% attack against Bitcoin, as OP so cogently explained, then how could the grey aliens not be involved!?  Try explaining that away, Segwit shill.

I know this is all true, because I read it on /r/btc.

But that’s not the worst.  There is a frightening secret to Segwit; but I can’t tell you about it, because theymos would ban me.

Preface:  You will be interested to read this old mailing list post.  The same issues have been rehashed for years, in a thousand different forms.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html


I think Segwit adoption has been slow because (0) client software support has been slow in developing, (1) there are organized anti-Segwit FUD campaigns on forums and social media (did you notice?), and (2) several major players desire forking and centralization of Bitcoin (“divide-and-conquer”/“unite and rule”).  Those last will play politics and apply extra fee pressure to their own users, for as long as they themselves can afford to continue doing so.  As the rest of the market adopts Segwit, that can’t be terribly long—competition being what it is.

As for incentives to adopt Lightning:

Hey, I heard that some people have been complaining just a wee little bit about on-chain fees.  That will be an incentive for people to use Lightning instead, for the transactions for which Lightning is more appropriate.  (Ironically, the offloading of transactions from the blockchain will then apply downward pressure on fees—albeit, as increased total Bitcoin usage and LN channel opening/closing transactions apply upward pressure, until fees reach some sort of new equilibrium.)

And people really do want to buy cups of coffee.  Speaking for myself, I love coffee.  I, too, want to efficiently buy cups of coffee with Bitcoin.  Coffee may be the best Lightning incentive of all!

As for incentivizing hubs, Lightning will also have fees, albeit drastically smaller fees.  You know the Bitcoin motto, “Be your own bank.”  My own observation:  On Lightning, anybody with the capital to provide liquidity for a busy hub can take up the motto, “Be your own mini-Visa.”  Visa takes a small cut every time somebody buys a cup of coffee with it; and most people still deem it fit for buying cups of coffee.

Now imagine if instead of a few centralized payment networks (Visa, Mastercard, and a few others), you could open payment channels of your choosing into a decentralized constellation of cooperating/competing Lightning payment hubs for your small-value consumer purchases.  I see plenty of incentives on all sides, there:  For consumers, for merchants, for hub providers.

By the way, one technical correction:


You are absolutely right about that importance.  But please be advised, there is no longer a 1MB block size limit.  Indeed, there is no more block size limit at all!  Segwit replaces the block size limit with a block weight limit, set to 4000000 bytes:


The total “weight” of transactions is limited as specified by BIP 141:


It sounds complicated; but this is actually designed to avoid making transaction selection more difficult for miners.

The way bytes are weighted, best estimates are that with full Segwit adoption, we will see blocks a bit over 2MB in actual size.  That’s just fine for the network, including nodes run on modest hardware and residential Internet connections.

Wherefore ideas such as Malice Reactive Proof of Work Additions (MR POWA) (blogged, reblogged, discussed on this forum—theymos immediately pointed out one obvious problem).  I do not endorse that proposal; I think it’s interesting, but I have no desire to see collateral damage made of all the fine folks who invested their lives’ savings in SHA-256 hardware, and swore they would mine Bitcoin or nothing.

Thus far, Bitcoin has successfully stared down threats and active attempts to cause exactly what you describe.  Anti-Core/anti-Segwit/pro-BCH/2X/whatever watering holes have been perpetually filled with talk of “the flippening” and “killing off the legacy chain” (i.e. Bitcoin), amidst much bravado.  At one point just last month, there was a serious contest of hashpower accompanied by market manipulations which pumped-and-dumped BCH, whilst knocking down Bitcoin down 30% for all of a few days.  This was timed carefully, so that the desertion of malicious miners would hit right after a 2016th-block difficulty adjustment.  Bitcoin got kind of slow, as its hashpower plummeted; BCH supporters were jeering that Bitcoin would grind to a halt, predicting that hashpower would drop low enough that it would take months to reach the next difficulty adjustment.  That situation lasted for approximately 48 hours, until miners flocked back to where they could make the biggest profits.  The end of that battle was that Bitcoin’s hashpower stabilized, little guys who threw their money into BCH at its peak got wiped out—and Bitcoin’s exchange rate rebounded to a new all-time high within a week or so, thus giving miners all the more reason to stay with Bitcoin!

The more often Bitcoin faces such attacks, the worse it crushes its attackers; and thus, the more of a reputation it gains for being “anti-fragile” and a “honey badger” (or “money badger”).  From a public relations perspective, attempts at “flippening” away Bitcoin by draining its hashpower have made those who try such things look ridiculous.

The war isn’t over, of course; and I myself am worried about miner centralization as a matter of principle.  It is most worrisome that the world’s biggest vendor of SHA-256 ASICs is actively pro-BCH/anti-Bitcoin, and currently accepting payment in BCH instead of Bitcoin.  I want to see commodity SHA-256 ASICs sold cheaper than GPUs, and as readily available.  I think that’s probably the best solution, long-term.  Too bad I am not a hardware guy.

Glad to hear it!


A question you should ponder:  Why don’t miners skip verifying all signatures, altogether?  That could be really profitable.  That way, they could seize and spend Satoshi’s coins!

Oh, wait:  They couldn’t do that, because the resulting blocks would be rejected by nodes as invalid.

But according to you, nothing whatsoever could stop them.  A miner could simply seize Satoshi’s coins with a consensus-invalid transaction, and other miners could build on that chain, and full nodes would be forced to follow along because they have no hashpower—right?

Segwit makes absolutely no difference whatsoever, in this regard.  The signatures are still there; they just got moved around a little bit.  Verification of the signatures is still required by consensus rules.  No substantive change has been made as to the security properties of Bitcoin’s signature verification.

Miners are perfectly free to mine invalid chains, if they want.  As I’ve said elsewhere, they can mine chains of blocks filled with the output of /dev/random in lieu of transactions, if they want.  But those invalid chains will not exist to the Bitcoin network.  “What full nodes think is valid or not” absolutely does affect the blockchain:  Indeed, that determines what the blockchain is.


You have it precisely backwards:  Hashpower follows value.  In the altcoin space, I’ve been fascinated to watch as an ASIC-resistant, GPU-mined coin’s mining difficulty rises and falls immediately following fluctuation of the ratio of its value to the value of other GPU-mined coins.  Of course, many big mining farms have the switch set to occur automatically.

Bitcoin does not derive its value from mining hashpower.  Bitcoin’s value incentivizes and indeed, pays for hashpower.  As codewench says, if all the ASIC miners started churning out invalid blocks, Bitcoin could proceed with “an old Celeron”—but of course that would not happen, because miners want to make money.  Some miners such as Jihan (Bitmain) may have a long-term profit strategy driven by ulterior motives, and/or security exploits (substantially fixed by Segwit) which give them a profit advantage on a forkchain; and some may simply be fools, in the sense of bad businessmen.  But the rest will run to mine the coin with the highest value.  That is Bitcoin.  And to get their profits, the miners need their blocks to be accepted by full nodes—rejection by full nodes means no mining profits!  That’s one important part of what you keep missing.

More generally, you need to understand the purpose of mining.  I have repeatedly tried to explain that to you in these various different threads.  Look up Byzantine fault tolerance, the Byzantine generals problem, and the double-spend problem.  Start learning.


What you just said is such a long string of disconnected non sequitur that I don’t even know where to start.

The bird’s-eye overview of how Segwit actually works:  Segregated Witness transactions are serialized in such a manner that the “witness data” (public keys and signature) is dealt with separately from the input/output/script data, within the same block.  This permits witness data to be omitted in communications with old, non-upgraded nodes, and only with them.  Segwit nodes receive all transaction data, including signatures, within the same block.  None of this has anything to do with the UTXO set.

The principal purpose of segregating the witness data was to permit changing the blocksize without a hardfork.  Segwit doesn’t just change the blocksize limit:  It gets rid of the blocksize limit entirely.  Instead, Bitcoin now has a block weight limit of 4000000 bytes.  Transaction data in the old serialization format is weighted (much) more heavily; Segwit witness data is measured with much lighter “weight”, byte for byte.  The upshot is that old, non-upgraded nodes will continue seeing blocks with a maximum size of 1000000 bytes; whereas upgraded nodes can take advantage of larger blocks.  Instead of a hardfork which suddenly and totally breaks old nodes, we have a gradual transition which lets old nodes continue minimal function until their owners get around to upgrading.

That is the block capacity part of Segwit.  In my opinion, the most important parts of Segwit are that it also includes bugfixes for transaction malleability and the quadratic sighash scaling problem; and it includes a script versioning system, for forward-compatibility with future new features.  I’m not Litecoin user, but I do concur with what Charlie Lee said in favour of Segwit (as I just quoted in one of these other threads you started).  The block capacity upgrade was the smallest part of Segwit, so to speak.

Now unless you have something new to say, other than rehashing the same drastically incorrect bare assertions, or unless somebody else pipes up with something interesting, I will bow out of these threads for now so as to stop bumping them—and to not become this guy:

It has been investigated and confirmed that on popular social media such as Reddit, paid professional manipulators are using multiple accounts to push an agenda which is:  (0) Anti-Segwit; (1) anti-Core; (2) pro-BCH, and/or pro-other-forks.  Some of their usual claims, all factually false:  “Segwit removes signatures from transactions.”  “Segwit permits miners to steal the money from Segwit transactions.”  They also seize every opportunity to wring their hands about fees.  Sound familiar?

Now when you show up in the forum for Bitcoin Development & Technical Discussion and start prolifically posting on about multiple different threads with rhetoric such as “Segwit is a 51% attack on Bitcoin”, you should understand why I wax a wee bit suspicious.

I didn’t accuse you of being paid:  I flat-out asked if you were.  It’s a reasonable question.  N.b. that if you are not deliberately spreading disinformation, that implies you must be a victim of disinformation who continues to spread it as one infected by plague.


There is a common fallacy of falsely presuming oneself to have original ideas about problems which very smart people have pondered for years.  It seems that lately, half the new threads in this forum are by people who ignorantly claim to have “invented” some new idea or “discovered” some sort of unknown problem.  Almost without exception, the “new” ideas are rehashes of old ideas which were rejected long ago, because they are bad ideas; and the “unknown” problems are either very well known, or total non-problems.

It is easy to overestimate one’s own knowledge and frankly, one’s own competence.  The wise ones quietly learn until they know enough to know the limits of their own knowledge.  The fools open their mouths and start blabbering.

If you’re “new to crypto and 100% devoted”, I strongly urge you to study.  Read documentation, FAQs, source code.  Then after you have a sound basis for the beginning level of knowledge, ask intelligent questions—first in Beginners & Help for abstract conceptual questions, or Technical Support for questions about concrete usage of Bitcoin Core or the Bitcoin network.  This forum, “Development & Technical Discussion”, is for exactly that.  I don’t think it’s appropriate to even post here until after one has spent “100% devoted” time and effort acquiring genuine expertise.  All of us were once beginners, but this is not a forum for beginners.


I infer you mean Segwit.  As has been explained, that’s false.  But I will pretend here that you were referring to actual tampering with Bitcoin’s codebase.  That is a valid concern; and to be proactive in protecting the security of the code, Core was a pioneer in the application of deterministic builds.  If you have the skills (or can pay a security professional), you can download the Bitcoin source code, verify all pertinent PGP signatures on both code and binaries, audit the code, and then verify that the code you audited builds into binaries identical to the ones Core distributes.  This last is important to advanced security.  Core has made great effort to enable this type of auditing.

Bitcoin is decentralized.  This means that no one has the authority to force full nodes to accept invalid blocks.  Miners have no such authority, “drawn at random” or otherwise.

Make sense now?

Across multiple simultaneous threads, many smart people have shown excruciating patience in attempting to educate you on these technical issues.  Whereas you have shown yourself fully immune to all reason, ad hominem (L. “at the man”) examination of you personally is a perfectly valid means to prevent others from being misled by your disinformation campaign—or wasting their time with you.  For the benefit of others, per my above self-quote, I have also offered some concise technical explanations of where you are wrong.

Aside:  You are not entitled to an opinion, nor to a “counterargument”.  When you make an assertion of fact as to technical issues, then objectively, you are either right or wrong.  Persistently, incorrigibly, you have been wrong; and you still are.  By analogy, I would not deign to offer “counterarguments” to someone who claims that the Earth be flat.

You have severe reading comprehension problems if you think I suggested that you are Tom Zander.  No, I don’t think you are.  But it is evident that you are pushing an anti-nodes agenda.

So, you did not answer:  Are you being paid for these posts?  It’s a simple yes-or-no question.  There do exist people being paid to post on the Internet more or less exactly what you are saying.  On the other hand, their greatest friends are people who have nothing better to do than to unthinkingly repeat what they hear.

What the hell are you talking about?  Due to all the idiots trying to stop Segwit in Bitcoin, Litecoin activated Segwit before Bitcoin did.

Litecoin’s Charlie Lee is strongly pro-Segwit; so if you trust him, trust him on this:

---

No, you have it backwards:  It would be just as if the miners who are mining invalid blocks did not exist.

Any miner building further upon an invalid block would mining on invalid chain, and thus similarly would be ignored.

When you say nonsensical gibberish such as “bitcoin worked before anyone ever invented the ‘non-mining full node’”, you clearly demonstrate that you have not even the slightest inkling of how Bitcoin ever worked.  Nodes run the network, and always have.  Miners are employees paid handsomely to provide Byzantine fault-tolerant transaction ordering.  Do you even care what that means?  I ask rhetorically.

Please disclose, are you being paid for it?  If so, by whom?


In other words, alternative solutions would be to destroy Bitcoin.  Of course, that’s the agenda.

(To be clear, you are an intelligent poster; and I realize you were highlighting how stupid this whole discussion is.  But I think you were a bit too subtle for some of the types suddenly flooding in.)


Say what?  The decentralized, permissionless Bitcoin network, which vests users with all power over themselves and all responsibility for themselves, is “no different than a traditional bank”.  Its “whole point... is dissolved”.

Please sell all your bitcoins.  Dump BTC, right now!  Go back to the banks.  You won’t be missed.


And there, you have described the purpose of the fee market as a filter which stops people from filling a shared global commons with transactions not personally important to them.  If a transaction is not sufficiently important to you that you’re willing to either pay or wait, then it doesn’t belong on the blockchain.  Nodes don’t need an eternal archive of purchases of cups of coffee.  Lightning will handle those; better still, it will enable real micropayments.


I think he did think it through—or rather, somebody thought it through for him.  Never assume stupidity, when malice will suffice.


It gets comical when the idiotic forkers are referencing the arguments of forks dead and buried.


It bears emphasizing in all these conversations:  People who complain about fees to the point of derogating Bitcoin, are in essence complaining that their coins are too valuable, the network is too popular (= in high demand).

“My coins increased 1500% in real-world purchase power since I got them.  THIS IS HORRIBLE!  BITCOIN IS DEAD!  THE SKY IS FALLING!”

Well, either they’re that stupid—or they’re being paid to shill against Bitcoin.


There are two schools of thought here:  “ASICs are bad”, thus certain altcoins embracing memory-hard POW such as Equihash; and “ASICs are good”, and they should be commoditized.  The latter holds that ASIC-friendly algorithms benefit the security of the network by making ASICs (relatively) cheaper and easier to produce.

ASIC-resistance seems a fool’s errand; but also the ASIC-friendly argument falls down, kicked down by the huge footprint of Jihan.  I don’t think anybody yet has a good solution.  If Blockstream had the godlike powers ascribed to them by idiots, they should decree by fiat that $5 SHA-256 ASICs rain from the heavens.


Ah-hah, the anti-nodes agenda drops its mask!  The “full nodes do nothing for the network”, eh?


ir.hn, at this point I am reasonably certain that you are deliberately, maliciously lying.  You’ve been spamming your nonsense over multiple threads in a forum designated for well-informed technical discussion.  To all explanations, you counterargue with bare assertions.  But if you want to play stupid, go read my other recent reply, q.v.: