Bitcoin Dev Luke Jr: Mixing Bitcoins is Money Laundering ...
Bitcoin Dev Luke Jr: Mixing Bitcoins is Money Laundering ...
Luke Dashjr - Bitcoin Wiki
Luke Dashjr. All about cryptocurrency - BitcoinWiki
Mining-Pool-Liste. Alles über Kryptowährung - BitcoinWiki
User:Luke-jr - Bitcoin Wiki
Luke-Jr decides to rename "paper wallet" to "Paper ECDSA private keys" for all of us. Replaces all paper wallet information on the Bitcoin Wiki with what he prefers to use (HD mnemonic wallet backups).
Luke-Jr doesn't like paper wallets. To this end, he has renamed/moved the official Bitcoin wiki for "Paper Wallet" to "Paper ECDSA private keys", making it confusing and difficult for users to learn what a paper wallet is and how to stay safe when making one. Meanwhile, he has created a brand new "Paper wallet" page in which he redefines a paper wallet as a Armory/Electrum backup of a HD wallet mnemonic seed, and says that these should not be confused with what you and I and everyone else calls a paper wallet. The other contribution Luke-Jr made to the original paper wallet wiki was to unlink my own service (bitcoinpaperwallet.com) from the wiki, his reasoning being, "BitcoinPaperWallet was removed because it is a website for generating private keys". As someone who has put a lot of energy into paper wallet education and generally helping the bitcoin community with paper wallet generation, I find this utterly baffling. I don't want to get involved in a revision battle here. Luke-Jr has already started that, reverting any changes I make to the wiki instantly. If you have an opinion on this matter and you have bitcoin wiki editor privileges, please express it on the discussion page. Edit 1: you can also express opinions right here of course :) Edit 2: much of the discussion on this page is about whether or not paper wallets are a good idea, or if websites should be used to generate them. Can we at least agree that these pro/con arguments should appear on a wiki page called "paper wallets" so everyone can find them? If those arguments appear on a wiki page called "Paper ECDSA private keys" then nobody will see them. Edit 3: Gladoscc on the wiki has renamed "Paper ECDSA private keys" back to "Paper Wallet" as of 12:41 UTC, so you may be confused if you visit the wiki to see what all the hubbub is about -- unless his change has been reverted by the time you read this. :) Edit 4: Gladoscc's change didn't last for more than 24 hours before Luke-Jr re-reverted the changes, and then added in a confounding set of redirects in the wiki so that "Paper Wallet" redirects to "Paper wallet" which then redirects to his page on HD wallet mnemonic seeds. I cannot understand how this is supposed to help end users who want to learn what a paper wallet is (and why they're risky, and how hard it is to produce them in a safe way.)
Technical: The `SIGHASH_NOINPUT` Debate! Chaperones and output tagging and signature replay oh my!
Bitcoin price isn't moving oh no!!! You know WHAT ELSE isn't moving?? SIGHASH_NOINPUT that's what!!! Now as you should already know, Decker-Russell-Osuntokun ("eltoo") just ain't possible without SIGHASH_NOINPUT of some kind or other. And Decker-Russell-Osuntokun removes the toxic waste problem (i.e. old backups of your Poon-Dryja LN channels are actively dangerous and could lose your funds if you recover from them, or worse, your most hated enemy could acquire copies of your old state and make you lose funds). Decker-Russell-Osuntokun also allows multiparticipant offchain cryptocurrency update systems, without the drawback of a large unilateral close timeout that Decker-Wattenhofer does, making this construction better for use at the channel factory layer. Now cdecker already wrote a some code implementing SIGHASH_NOINPUT before, which would make it work in current pre-SegWit P2PKH, P2SH, as well as SegWit v0 P2WPKH and P2WSH. He also made and published BIP 118. But as is usual for Bitcoin Core development, this triggered debate, and thus many counterproposals were made and so on. Suffice it to say that the simple BIP 118 looks like it won't be coming into Bitcoin Core anytime soon (or possibly at all). First things first: This link contains all that you need to know, but hey, maybe you'll find my take more amusing. So let's start with the main issue.
Signature Replay Attack
SIGHASH_NOINPUT basically means "I am authorizing the spend of any coin of this particular value protected by my key, to be spent to these addresses".
Of note is that the default SIGHASH_ALL means "I am authorizing the spend of this particular coin of this particular value protected by my key, to be spent to these addresses".
So suppose you were to engage in address reuse. This is highly discouraged behavior, but people are people, people are lazy, and etc. etc. In practice it happens.
Now suppose you had two deposits of equal size, in the same address that you have been reusing.
Now further suppose that for some reason, your wallet signs using SIGHASH_NOINPUT only. luke-jr has even promised to write one when SIGHASH_NOINPUT is implemented, so you don't even need to go search for one, you just pester luke-jr to release it.
So you got two UTXOs, of equal value, to the same address.
You spend one UTXO, signing with SIGHASH_NOINPUT, to pay almkglor because he's so awesome at explaining Bitcoin things and deserves to be paid for it.
almkglor realizes you've used SIGHASH_NOINPUTand that you engaged in address reuse. He writes a new transaction spending your other UTXO of same value and same address, reusing the same signature ("Signature Replay") that was publicly attached to your previous tx. The signature authorizes the spend of any coin protected by that key.
Since luke-jr is strongly against address reuse, he will just LOL at you for doing address reuse with his wallet software and mark your bugreports with wontfix, gendopose, allaccordingtothescenario.
The above is the Signature Replay Attack, and the reason why SIGHASH_NOINPUT has triggered debate as to whether it is safe at all and whether we can add enough stuff to it to ever make it safe. Now of course you could point to SIGHASH_NONE which is even worse because all it does is say "I am authorizing the spend of this particular coin of this particular value protected by my key" without any further restrictions like which outputs it goes to. But then SIGHASH_NONE is intended to be used to sacrifice your money to the miners, for example if it's a dust attack trying to get you to spend, so you broadcast a SIGHASH_NONE signature and some enterprising miner will go get a bunch of such SIGHASH_NONE signatures and gather up the dust in a transaction that pays to nobody and gets all the funds as fees. And besides; even if we already have something you could do stupid things with, it's not a justification for adding more things you could do stupid things with. So yes, SIGHASH_NOINPUT makes Bitcoin more powerful. Now, Bitcoin is a strong believer in "Principle of Least Power". So adding more power to Bitcoin via SIGHASH_NOINPUT is a violation of Principle of Least Power, at least to those arguing to add even more limits to SIGHASH_NOINPUT. I believe nullc is one of those who strongly urges for adding more limits to SIGHASH_NOINPUT, because it distracts him from taking pictures of his autonomous non-human neighbor, a rather handsome gray fox, but also because it could be used as the excuse for the next MtGox, where a large exchange inadvertently pays to SIGHASH_NOINPUT-using addresses and becomes liable/loses track of their funds when signature replay happens.
Making SIGHASH_NOINPUT safer by not allowing normal addresses use it. Basically, we have 32 different SegWit versions. The current SegWit addresses are v0, the next version (v1) is likely to be the Schnorr+Taproot+MAST thing. What output tagging proposes is to limit SegWit version ranges from 0->15 in the bech32 address scheme (instead of 0->31 it currently has). Versions 16 to 31 are then not valid bech32 SegWit addresses and exchanges shouldn't pay to it. Then, we allow the use of SIGHASH_NOINPUT only for version 16. Version 16 might very well be Schnorr+Taproot+MAST, with a side serving of SIGHASH_NOINPUT. This is basically output tagging. SIGHASH_NOINPUT can only be used if the output is tagged (by paying to version 16 SegWit) to allow it, and addresses do not allow outputs to be tagged as such, removing the potential liability of large custodial services like exchanges. Now, Decker-Russell-Osuntokun channels have two options:
Make the funding txo pay to a version 16 SegWit.
Make the funding txo pay to a version 0/1 SegWit.
The tradeoffs in this case are:
If the funding txo pays to a version 16 SegWit, then anyone analyzing the blockchain can point at a version 16 SegWit txo and conclude it was used for the Lightning Network, because seriously, there's little other use for SIGHASH_NOINPUT other than that (well there's certain limited kinds of vault-like constructions, but for the most part, the balance of probability will be that it's a LN channel).
Of note is that even non-published channels will likely be trackable via the funding txo paying to version 16 SegWit, which is published onchain.
Also, current already-closed published Poon-Dryja channels, that are closed by mutual close instead of unilateral, are indistinguishable onchain from ordinary spends. Trackers that want to keep track of Lightning usage need to store the information themselves, about such published channels that have been closed; the LN won't store it for them, so that at least moves the burden of storing that information to the surveillors, and fuck them anyway.
If the funding txo pays to a version 0/1 SegWit, then in the unilateral case we need to have an additional transaction that takes the funding txo and pays to a version 16 SegWit. This adds more overhead in the unilateral close case, and unilateral close in Decker-Russell-Osuntokun already needs two txes (an update and settlement tx); this adds one more tx, a "converter" from version 0/1 SegWit to version 16 SegWit.
This lets mutual closes indistinguishable from ordinary spends onchain. Unilateral closes are still obvious, but even today in the Poon-Dryja world unilateral closes are plenty darn obvious (very specific SCRIPT templates are used).
The latter tradeoff is probably what would be taken (because we're willing to pay for privacy) if Bitcoin Core decides in favor of tagged outputs. Another issue here is --- oops, P2SH-Segwit wrapped addresses. P2SH can be used to wrap any SegWit payment script, including payments to any SegWit version, including v16. So now you can sneak in a SIGHASH_NOINPUT-enabled SegWit v16 inside an ordinary P2SH that wraps a SegWit payment. One easy way to close this is just to disallow P2SH-SegWit from being valid if it's spending to SegWit version >= 16.
Closing the Signature Replay Attack by adding a chaperone. Now we can observe that the Signature Replay Attack is possible because only one signature is needed, and that signature allows any coin of appropriate value to be spent. Adding a chaperone signature simply means requiring that the SCRIPT involved have at least two OP_CHECKSIG operations. If one signature is SIGHASH_NOINPUT, then at least one other signature (the chaperone) validated by the SCRIPT should be SIGHASH_ALL. This is not so onerous for Decker-Russell-Osuntokun. Both sides can use a MuSig of their keys, to be used for the SIGHASH_NOINPUT signature (so requires both of them to agree on a particular update), then use a shared ECDH key, to be used for the SIGHASH_ALL signature (allows either of them to publish the unilateral close once the update has been agreed upon). Of course, the simplest thing to do would be for a BOLT spec to say "just use this spec-defined private key k so we can sidestep the Chaperone Signatures thing". That removes the need to coordinate to define a shared ECDH key during channel establishment: just use the spec-indicated key, which is shared to all LN implementations. But now look at what we've done! We've subverted the supposed solution of Chaperone Signatures, making them effectively not there, because it's just much easier for everyone to use a standard private key for the chaperone signature than to derive a separate new keypair for the Chaperone. So chaperone signatures aren't much better than just doing SIGHASH_NOINPUT by itself, and you might as well just use SIGHASH_NOINPUT without adding chaperones. I believe ajtowns is the primary proponent of this proposal.
Toys for the Big Boys
The Signature Replay Attack is Not A Problem (TM). This position is most strongly held by RustyReddit I believe (he's the Rusty Russell in the Decker-Russell-Osuntokun). As I understand it, he is more willing to not see SIGHASH_NOINPUT enabled, than to have it enabled but with restrictions like Output Tagging or Chaperone Signatures. Basically, the idea is: don't use SIGHASH_NOINPUT for normal wallets, in much the same way you don't use SIGHASH_NONE for normal wallets. If you want to do address reuse, don't use wallet software made by luke-jr that specifically screws with your ability to do address reuse. SIGHASH_NOINPUT is a flag for use by responsible, mutually-consenting adults who want to settle down some satoshis and form a channel together. It is not something that immature youngsters should be playing around with, not until they find a channel counterparty that will treat this responsibility properly. And if those immature youngsters playing with their SIGHASH_NOINPUT flags get into trouble and, you know, lose their funds (as fooling around with SIGHASH_NOINPUT is wont to do), well, they need counseling and advice ("not your keys not your coins", "hodl", "SIGHASH_NOINPUT is not a toy, but something special, reserved for those willing to take on the responsibility of making channels according to the words of Decker-Russell-Osuntokun"...).
Dunno yet. It's still being debated! So yeah. SIGHASH_NOINPUT isn't moving, just like Bitcoin's price!!! YAAAAAAAAAAAAAAAAAAA.
Newbs might not know this, but bitcoin recently came out of an intense internal drama. Between July 2015 and August 2017 bitcoin was attacked by external forces who were hoping to destroy the very properties that made bitcoin valuable in the first place. This culminated in the creation of segwit and the UASF (user activated soft fork) movement. The UASF was successful, segwit was added to bitcoin and with that the anti-decentralization side left bitcoin altogether and created their own altcoin called bcash. Bitcoin's price was $2500, soon after segwit was activated the price doubled to $5000 and continued rising until a top of $20000 before correcting to where we are today. During this drama, I took time away from writing open source code to help educate and argue on reddit, twitter and other social media. I came up with a reading list for quickly copypasting things. It may be interesting today for newbs or anyone who wants a history lesson on what exactly happened during those two years when bitcoin's very existence as a decentralized low-trust currency was questioned. Now the fight has essentially been won, I try not to comment on reddit that much anymore. There's nothing left to do except wait for Lightning and similar tech to become mature (or better yet, help code it and test it) In this thread you can learn about block sizes, latency, decentralization, segwit, ASICBOOST, lightning network and all the other issues that were debated endlessly for over two years. So when someone tries to get you to invest in bcash, remind them of the time they supported Bitcoin Unlimited. For more threads like this see UASF
A brief teardown of some of the flaws in the Lightning Network white paper
This post will perforce be quick and sloppy, because I have other things to do. But a recent comment provoked me to re-read the Lightning white paper to remind myself of the myriad flaws in it, so I decided to at least begin a debunking. When I first read the Lightning white paper back in early 2016, the sheer audacity of the author's preposterous claims and their failure to understand basic principles of the Satoshi paper just offended the living shit out of me. I presumed - incorrectly - that the Lightning paper would be soon torn to shreds through peer review. However Core was successful in suppressing peer review of the paper, and instead inserted Lighting as their end-all be-all scaling plan for Bitcoin. I'm sorry I didn't post this in 2016, but better later than never. Let's start with the abstract.
The bitcoin protocol can encompass the global financial transaction volume in all electronic payment systems today, without a single custodial third party holding funds or requiring participants to have anything more than a computer using a broadband connection.
Well now, that's an awfully gigantic claim for someone that hasn't even written a single line of code as a proof of concept don't you think? This is what's called "overpromising," the Nirvana fallacy, or more appropriately, "vaporware" - that is to say, a pie-in-the-sky software promise intended to derail progress on alternatives. In the very first sentence, the authors claim that they can scale Bitcoin to support every transaction that ever happens, from micropayments to multibillion dollar transfers, with no custodial risk, on a simple computer with nothing more than broadband. It will be perfect. Honestly everyone should have put the paper down at the first sentence, but let's go on.
A decentralized system is proposed
The authors claim that the system proposed is decentralized, but without even a single line of code (and indeed no solution to the problem they claim is the issue, more on that later) they have zero defense of this claim. In fact, the only known solution to the problem that Lightning cannot solve is centralized hubs. We'll get back to this.
whereby transactions are sent over a network of micropayment channels (a.k.a. payment channels or transaction channels) whose transfer of value occurs off-blockchain. If Bitcoin transactions can be signed with a new sighash type that addresses malleability, these transfers may occur between untrusted parties along the transfer route by contracts which, in the event of uncooperative or hostile participants, are enforceable via broadcast over the bitcoin blockchain in the event of uncooperative or hostile participants, through a series of decrementing timelocks
So right here in the abstract we have the promise: "support the entire world's transaction needs on a measly computer with just broadband, totally decentralized, and... (drum roll please) all that's missing is Segwit." Yeah right. Let's continue. First sentence of the paper itself reads:
The Bitcoin blockchain holds great promise for distributed ledgers, but the blockchain as a payment platform, by itself, cannot cover the world’s commerce anytime in the near future.
So the authors have constructed a false problem they claim to solve: scaling Bitcoin to cover every transaction on Earth. Now, that would be neato if it worked (it doesn't) but really, this is like Amerigo Vespucci claiming that the problem with boats is that the sails aren't big enough to carry it to the moon. We aren't ready for that part yet. . In infotech we have a saying, "crawl, walk, run." Lightning's authors are going to ignore "walking" and go from crawling to lightspeed. Using the logic of this first sentence, Visa never should have rolled out its original paper-based credit cards, because "obviously they can't scale to solve the whole world's financial needs." Again, your bullshit detector should be lighting up. Next sentence. So why can't Bitcoin cover all the world's financial transactions?
The blockchain is a gossip protocol whereby all state modifications to the ledger are broadcast to all participants. It is through this “gossip protocol” that consensus of the state, everyone’s balances, is agreed upon.
Got it. The problem is the "gossip protocol." That's bad because...
If each node in the bitcoin network must know about every single transaction that occurs globally, that may create a significant drag on the ability of the network to encompass all global financial transactions
OK. The problem with Bitcoin, according to the author, is that since every node must know the current state of the network, it won't scale. We'll get back to this bit later, because this is the crux: Lightning has the same problem, only worse. Now the authors take a break in the discussion to create a false premise surrounding the Visa network:
The payment network Visa achieved 47,000 peak transactions per second (tps) on its network during the 2013 holidays, and currently averages hundreds of millions per day. Currently, Bitcoin supports less than 7 transactions per second with a 1 megabyte block limit. If we use an average of 300 bytes per bitcoin transaction and assumed unlimited block sizes, an equivalent capacity to peak Visa transaction volume of 47,000/tps would be nearly 8 gigabytes per Bitcoin block, every ten minutes on average. Continuously, that would be over 400 terabytes of data per year.
I'll just point out that Visa itself cannot sustain 47K tpscontinuously, as a reminder to everyone that the author is deliberately inflating numbers to make them seem more scary. Again, is your bullshit detector going off yet? Now we get to the hard-sell:
Clearly, achieving Visa-like capacity on the Bitcoin network isn’t feasible today.
So the author deliberately inflates Visa's capabilities then uses that to say clearly it just can't be done. But really, Visa's actual steady-state load can be accomplished in roughly 500MB blocks - which actually is feasible, or nearly so, today. 500MB every ten minutes is actually a small load of data for a decent-sized business. There are thousands of companies that could quite easily support such a load. And that's setting aside the point that we took 7 years to get to 1MB, so it's unlikely that we'll need 500X that capacity "in the near future" or "today" as the authors keep asserting.
No home computer in the world can operate with that kind of bandwidth and storage.
whoopsie!! Did he say, home computer?? Since when did ordinary Bitcoin users have to keep the whole blockchain on their home computers? Have the authors of the Lightning white paper ever read the Satoshi white paper, which explains that this is not the desired model in Section 8? Clearly the Lightning authors are expecting their readers to be ignorant of the intended design of the Bitcoin network. This is a classic example of inserting a statement that the reader is unlikely to challenge, which completely distorts the discussion. Almost nobody needs to run a fullnode on their home computer! Read the Satoshi paper!
If Bitcoin is to replace all electronic payments in the future, and not just Visa, it would result in outright collapse of the Bitcoin network
Really? Is that so? Isn't the real question how fast will Bitcoin reach these levels of adoption? Isn't the author simply making an assumption that adoption will outpace advances in hardware and software, based on using wildly inflated throughput numbers (47K tps) in the first place? But no, the author makes an unfounded, unsupportable, incorrect blanket assertion that -- even in the future -- trying to scale up onchain will be the death of the entire system.
or at best, extreme centralization of Bitcoin nodes and miners to the only ones who could afford it.
Again, that depends on when this goes down. If Bitcoin grows at roughly the rate of advancement in hardware and software, then the cost to . independently validate transactions - something no individual user needs to do in the first place - actually stays perfectly flat. But the best part is that his statement:
centralization of Bitcoin nodes and miners to the only ones who could afford it
Ummm... mining and independent validation has always been limited to those who can afford it. What big-blockers know is that the trick isn't trying to make Bitcoin so tiny that farmers in sub-Saharan Africa can "validate" the blockchain on a $0.01 computer, but rather to expand adoption so greatly that they never have to independently validate it. Running scalable validation nodes at home is dumb. But, there are already millions of people with synchronous gigabit internet at home and more than enough wealth to afford a beefy home computer. The problem is that none of them are using Bitcoin. Adoption is the key!
This centralization would then defeat aspects of network decentralization that make Bitcoin secure, as the ability for entities to validate the chain is what allows Bitcoin to ensure ledger accuracy and security
Here the author throws a red herring across the trail for gullible readers. It is not my ability to validate the chain that produces trustlessness. If that was the case, there would be no need for miners. Users would simply accept or not accept other people's transactions based on their software's interpretation of validity. The Satoshi paper makes it quite clear where trustlessness is born: it is in the incentives that enforce honest mining of an uncorrupted chain. In other words, I don't have to validate the chain, but Poloniex does. And, newsflash, big companies can very easily afford big validation nodes. "$20K nodes" is a bullshit number I hear thrown around a lot. There are literally hundreds of thousands of companies that can easily afford $20K nodes in the event that Bitcoin becomes "bigger than Visa." Again, the trick is getting many companies in every jurisdiction in the world onto the blockchain. Then no individuals ever need to worry about censorship. Adoption! let's continue. I'll skip a few sentences.
Extremely large blocks, for example in the above case of 8 gigabytes every 10 minutes on average, would imply that only a few parties would be able to do block validation
If this were written in 1997 it would have read
Extremely large blocks, for example in the above case of 8 megabytes every 10 minutes on average, would imply that only a few parties would be able to do block validation
Obviously, we are processing 8MB blocks today. The real question is how long before we get there. At current rates of adoption, we'll all be fucking dead before anyone mines an 8GB block. And remember, 8GB was the number the authors cooked up. Even Visa can't handle that load, today, continuously.
This creates a great possibility that entities will end up trusting centralized parties. Having privileged, trusted parties creates a social trap whereby the central party will not act in the interest of an individual (principalagent problem), e.g. rentierism by charging higher fees to mitigate the incentive to act dishonestly. In extreme cases, this manifests as individuals sending funds to centralized trusted custodians who have full custody of customers’ funds. Such arrangements, as are common today, create severe counterparty risk. A prerequisite to prevent that kind of centralization from occurring would require the ability for bitcoin to be validated by a single consumer-level computer on a home broadband connection.
Here the author (using his wildly inflated requirement of 8GB blocks) creates a cloud of fear, uncertainty, and doubt that "Bitcoin will fail if it succeeds" - and the solution is, as any UASFer will tell you, that everyone needs to validate the chain on a weak fullnode running on a cheap computer with average internet connectivity. How's the bullshit detector going? Now the authors make a head-fake in the direction of honesty:
While it is possible that Moore’s Law will continue indefinitely, and the computational capacity for nodes to cost-effectively compute multigigabyte blocks may exist in the future, it is not a certainty.
Certainty? No. But, we should point out, the capacity to actually approach Visa is already at hand and in the next ten years is a near certainty in fact. But, surely, the solution that the authors propose is "around the corner" (- Luke-jr) ... /s . No, folks. Bigger blocks are the closest thing to "scaling certainty" that we have. More coming up....
To achieve much higher than 47,000 transactions per second using Bitcoin requires conducting transactions off the Bitcoin blockchain itself.
Now we get to the meat of the propaganda. To reach a number that Visa itself cannot sustain will "never" be possible on a blockchain. NEVER?? That's just false. In fact, I'll go on record as saying that Bitcoin will hit Visa-like levels of throughput onchain before Lightning Network ever meets the specification announced in this white paper.
It would be even better if the bitcoin network supported a near-unlimited number of transactions per second with extremely low fees for micropayments.
Yes, and it would also be even better if we had fusion and jetpacks. The thing is, these things that are promised as having been solved... have not been solved and no solution is in sight.
Many micropayments can be sent sequentially between two parties to enable any size of payments.
No, this is plain false. Once a channel's funds have been pushed to one side of the channel, no more micropayments in that direction can be made. This is called channel exhaustion and is one of the many unsolved problems of Lightning Network. But here the authors declare it as a solved problem. That's just false.
Micropayments would enable unbunding, less trust and commodification of services, such as payments for per-megabyte internet service. To be able to achieve these micropayment use cases, however, would require severely reducing the amount of transactions that end up being broadcast on the global Bitcoin blockchain
Now I'm confused. Is Lightning a solution for all the world's financial transactions or is it a solution for micropayments for things like pay-per-megabyte internet?
While it is possible to scale at a small level, it is absolutely not possible to handle a large amount of micropayments on the network or to encompass all global transactions.
There it is again, the promise that Lightning will "encompass all global transactions." Bullshit detector is now pegged in the red.
For bitcoin to succeed, it requires confidence that if it were to become extremely popular, its current advantages stemming from decentralization will continue to exist. In order for people today to believe that Bitcoin will work tomorrow, Bitcoin needs to resolve the issue of block size centralization effects; large blocks implicitly create trusted custodians and significantly higher fees. . (emphasis mine)
"Large" is a term of art which means "be afraid." In 1997, 8MB would have been an unthinkably large block. Now we run them live in production without breaking a sweat. "Large" is a number that changes over time. . By the time Bitcoin reaches "Visa-like levels of adoption" it's very likely that what we consider "large" today (32MB?) will seem absolutely puny. As someone who first started programming on a computer that had what was at the time industry-leading 64KB of RAM (after expanding the memory with an extra 16K add-on card) and a pair of 144KB floppy disks, all I can tell you is that humans are profoundly bad at estimating compounding effects and the author of the Lightning paper is flat-out banking on this to sell his snake oil. Now things are about to get really, really good.
A Network of Micropayment Channels Can Solve Scalability “If a tree falls in the forest and no one is around to hear it, does it make a sound?”
Here's where the formal line by line breakdown will come to an end, because this is where the trap the Lightning authors have set will close on them. Let's just read a bit further:
The above quote questions the relevance of unobserved events —if nobody hears the tree fall, whether it made a sound or not is of no consequence. Similarly, in the blockchain, if only two participants care about an everyday recurring transaction, it’s not necessary for all other nodes in the bitcoin network to know about that transaction
Here and elsewhere the author of the paper is implying that two parties can transact between them without having to announce the state of their channel to anyone else. We see this trope repeated time and time again by LN shills. "Not everyone in the world needs to know about my coffee transaction" they say, as if programmed. To see the obvious, glaring defect here requires an understanding of what Lightning Network purports to be able to do, one day, if it's ever finished. Payment channels, which Lightning is based on, have been around since Satoshi and are nothing new at all. It is and has always been possible to create a payment channel with your coffee shop, put $50 in it, and pay it out over a period of time until it's depleted and the coffee shop owner closes the channel. That's not rocket science, that's original Bitcoin. What Lightning purports to be able to do is to allow you to route a payment to someone else by using the funds in your coffee shop channel. IN this model, lets suppose Alice is the customer and Bob is the shop. Let's also suppose that Charlie is a customer of Dave's coffee shop. Ernie is a customer of both Bob and Dave's shop. Now, Alice would like to send money to Charlie. This could be accomplished by:
Alice moves funds to Bob
Bob moves funds to Ernie
Ernie moves funds to Dave
Dave moves funds to Charlie
or more simply, A-B-E-D-C Here's the catch. To pull this off, Alice has to be able to find the route to Charlie. This means that B-C-E and D all have to be online. So first off, all parties to a transaction and in a route must be online and we must know their current online status to even begin the process. Again: to use Lightning as described in its white paper requires everyone to always be online. If we accept centralized routing hubs, then only the hubs need to be online, but Lightning proposed to be decentralized, which means, essentially, everyone needs to always be online. Next, we need to know there are enough funds in all channels to perform the routing. Let's say Alice has $100 in her channel with Bob and wants to send this to Charlie. But Bob has only $5 in his channel with Ernie. sad trombone . The maximum that the route can support is $5. (Edit: not quite right, I cleaned this up here.) Notice something? Alice has to know the state of every channel through which she intends to route funds. When the author claims
if only two participants care about an everyday recurring transaction, it’s not necessary for all other nodes in the bitcoin network to know about that transaction
That's true -- unless you want to use the Lightning Network to route funds - and routing funds is the whole point. Otherwise, Lightning is just another word for "payment channels." The whole magic that they promised was using micropayments to route money anywhere. If you want to route funds, then you absolutely need to know the state of these channels. Which ones? That's the kicker - you essentially have to know all of them, to find the best route - and, sadly - it might be the case that no route is available - which requires an exhaustive search. And in fact, here we are over 18 months since this paper was published, and guess what? The problem of the "gossip protocol" - the very Achille's Heel of Bitcoin according to the author - has been solved with drum roll please --- the gossip protocol. (more info here) Because, when you break it down, in order for Alice to find that route to Charlie, she has to know the complete, current state of Bob-Ernie, Ernie-Dave, and Charlie-Dave. IF the Lightning Network doesn't keep *every participant up to date with the latest network state, it can't find a route. So the solution to the gossip protocol is in fact the gossip protocol. And - folks - this isn't news. Here's a post from ONE YEAR AGO explaining this very problem. But wait. It gets worse.... Let's circle around to the beginning. The whole point of Lightning, in a nutshell, can be described as fixing "Bitcoin can't scale because every node needs to know every transaction." It is true that every node needs to know every transaction. However: because we read the Satoshi white paper we know that not every user needs to run a node to validate his transactions. End-users should use SPV, which do not need to be kept up to date on everyone else's transactions. So, with onchain Bitcoin, you have something on the order of 10K "nodes" (validation nodes and miners) that must receive the "gossip" and the other million or so users just connect and disconnect when they need to transact. This scales. In contrast, with Lightning, every user needs to receive the "gossip." This does not scale. Note something else? Lightning purports to be an excellent solution to "streaming micropayments." But such micropayments would result in literally millions or billions of continuous state-changes to the network. There's no way to "gossip" millions of micropayment streams each creating millions of tiny transactions. Now, there is a way to make Lightning scale. It's called the "routing hub." In this model, end-users don't need to know the state of the network. Instead, they will form channels with trusted hubs who will perform the routing on their behalf. A simple example illustrates. IN our previous example, Alice wants to send money to Charlie, but has to find a route to him. An easy solution is to insert Frank. Frank holds 100K btc and can form bidirectional channels with Alice, Bob, Charlie, Dave, Ernie, and most everyone else too. By doing so, he places himself in the middle of a routing network, and then all payments come through Frank. Note that the only barrier to creating channels is capital. Lightning will scale, if we include highly-capitalized hubs as middlemen for everyone else to connect to. If the flaw here is not obvious then someone else can explain. Well. As Mark Twain once quipped, "if I had more time I would have written a shorter letter." I'll stop here. Hopefully this goes at least part of the way towards helping the community understand just how toxic and deceptive this white paper was to the community. Everyone on the Segwit chain has bet the entire future of Segwit-enabled Bitcoin on this unworkable house-of-cards sham. The rest of us, well, we took evasive action, and are just waiting for the rest of the gullible, brainwashed masses to wake up to their error, if they ever do. H/T: jonald_fyookball for provoking this Edit: fixed wrong names in my A-B-C-D-E example; formatting
Lightning Network Will Likely Fail Due To Several Possible Reasons
ECONOMIC CASE IS ABSENT FOR MANY TRANSACTIONS The median Bitcoin (BTC) fee is $14.41 currently. This has gone parabolic in the past few days. So, let’s use a number before this parabolic rise, which was $3.80. Using this number, opening and closing a Lightning Network (LN) channel means that you will pay $7.60 in fees. Most likely, the fee will be much higher for two reasons:
BTC fees have been trending higher all year and will be higher by the time LN is ready
When you are in the shoe store or restaurant, you will likely pay a higher fee so that you are not waiting there for one or more hours for confirmation.
Let’s say hypothetically that Visa or Paypal charges $1 per transaction. This means that Alice and Carol would need to do 8 or more LN transactions, otherwise it would be cheaper to use Visa or Paypal. But it gets worse. Visa doesn’t charge the customer. To you, Visa and Cash are free. You would have no economic incentive to use BTC and LN. Also, Visa does not charge $1 per transaction. They charge 3%, which is 60 cents on a $20 widget. Let’s say that merchants discount their widgets by 60 cents for non-Visa purchases, to pass the savings onto the customer. Nevertheless, no one is going to use BTC and LN to buy the widget unless 2 things happen:
they buy more than 13 widgets from the same store ($7.60 divided by 60 cents)
they know ahead of time that they will do this with that same store
This means that if you’re traveling, or want to tip content producers on the internet, you will likely not use BTC and LN. If you and your spouse want to try out a new restaurant, you will not use BTC and LN. If you buy shoes, you will not use BTC and LN. ROAD BLOCKS FROM INSUFFICIENT FUNDS Some argue that you do not need to open a channel to everyone, if there’s a route to that merchant. This article explains that if LN is a like a distributed mesh network, then another problem exists:
"third party needs to possess the necessary capital to process the transaction. If Alice and Bob do not have an open channel, and Alice wants to send Bob .5 BTC, they'll both need to be connected to a third party (or a series of 3rd parties). Say if Charles (the third party) only possesses .4 BTC in his respective payment channels with the other users, the transaction will not be able to go through that route. The longer the route, the more likely that a third party does not possess the requisite amount of BTC, thereby making it a useless connection.”
CENTRALIZATION According to this visualization of LN on testnet, LN will be centralized around major hubs. It might be even more centralized than this visualization if the following are true:
Users will want to connect to large hubs to minimize the number of times they need to open/close channels, which incur fees
LN’s security and usability relies on 100% uptime of relaying parties
Only large hubs with a lot of liquidity will be able to make money
Hubs or intermediary nodes will need to be licensed as money transmitters, centralizing LN to exchanges and banks as large hubs
“…applicability of the regulations … to persons creating, obtaining, distributing, exchanging, accepting, or transmitting virtual currencies.” “…an administrator or exchanger is an MSB under FinCEN's regulations, specifically, a money transmitter…” "An administrator or exchanger that (1) accepts and transmits a convertible virtual currency or (2) buys or sells convertible virtual currency for any reason is a money transmitter under FinCEN's regulations…” "FinCEN's regulations define the term "money transmitter" as a person that provides money transmission services, or any other person engaged in the transfer of funds. The term "money transmission services" means "the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means.”” "The definition of a money transmitter does not differentiate between real currencies and convertible virtual currencies.”
"An “informal value transfer system” refers to any system, mechanism, or network of people that receives money for the purpose of making the funds or an equivalent value payable to a third party in another geographic location, whether or not in the same form.” “…IVTS… must comply with all BSA registration, recordkeeping, reporting and AML program requirements. “Money transmitting” occurs when funds are transferred on behalf of the public by any and all means including, but not limited to, transfers within the United States or to locations abroad…regulations require all money transmitting businesses…to register with FinCEN."
Mike Caldwell used to accept and mail bitcoins. Customers sent him bitcoins and he mailed physical bitcoins back or to a designated recipient. There is no exchange from one type of currency to another. FinCEN told him that he needed to be licensed as money transmitter, after which Caldwell stopped mailing out bitcoins. ARGUMENTS AGAINST NEED FOR LICENSING Some have argued that LN does not transfer BTC until the channel is closed on the blockchain. This is not a defence, since channels will close on the blockchain. Some have argued that LN nodes do not take ownership of funds. Is this really true? Is this argument based on a technicality or hoping for a loophole? It seems intuitive that a good prosecutor can easily defeat this argument. Even if this loophole exists, can we count on the government to never close this loophole? So, will LN hubs and intermediary nodes need to be licensed as money transmitters? If so, then Bob, who is the intermediary between Alice and Carol, will need a license. But Bob won’t have the money nor qualifications. Money transmitters need to pay $25,000 to $1 million, maintain capital levels and are subject to KYC/AML regulations1. In which case, LN will have mainly large hubs, run by financial firms, such as banks and exchanges. Will the banks want this? Likely. Will they lobby the government to get it? Likely. Some may be wondering about miners. FinCEN has declared that miners are not money transmitters: https://coincenter.org/entry/aml-kyc-tokens :
"Subsequent administrative rulings clarified several remaining ambiguities: miners are not money transmitters…"
FinCEN Declares Bitcoin Miners, Investors Aren't Money Transmitters Some argue that LN nodes will go through Tor and be anonymous. For this to work, will all of the nodes connecting to it, need to run Tor? If so, then how likely will this happen and will all of these people need to run Tor on every device (laptop, phone and tablet)? Furthermore, everyone of these people will be need to be sufficiently tech savvy to download, install and set up Tor. Will the common person be able to do this? Also, will law-abiding nodes, such as retailers or banks, risk their own livelihood by connecting to an illegal node? What is the likelihood of this? Some argue that unlicensed LN hubs can run in foreign countries. Not true. According to FinCEN: "“Money transmitting” occurs when funds are…transfers within the United States or to locations abroad…” Also, foreign companies are not immune from the laws of other countries which have extradition agreements. The U.S. government has sued European banks over the LIBOR scandal. The U.S. government has charged foreign banks for money laundering and two of those banks pleaded guilty. Furthermore, most countries have similar laws. It is no coincidence that European exchanges comply with KYC/AML. Will licensed, regulated LN hubs connect to LN nodes behind Tor or in foreign countries? Unlikely. Will Amazon or eBay connect to LN nodes behind Tor or in foreign countries? Unlikely. If you want to buy from Amazon, you’ll likely need to register yourself at a licensed, regulated LN hub, which means you’ll need to provide your identification photo. Say goodbye to a censorship-resistant, trust-less and permission-less coin. For a preview of what LN will probably look like, look at Coinbase or other large exchanges. It’s a centralized, regulated and censored hub. Coinbase allows users to send to each other off-chain. Coinbase provides user data to the IRS and disallows users from certain countries to sell BTC. You need to trust that no rogue employee in the exchange will steal your funds, or that a bank will not confiscate your funds as banks did in Cyprus. What if the government provides a list of users, who are late with their tax returns, to Coinbase and tells Coinbase to block those users from making transactions? You need Coinbase’s permission. This would be the antithesis of why Satoshi created Bitcoin. NEED TO REPORT TO IRS The IRS has a definition for “third party settlement organization” and these need to report transactions to the IRS. Though we do not know for sure yet, it can be argued that LN hubs satisfies this definition. If this is the case, who will be willing to be LN hubs, other than banks and exchanges? To read about the discussion, go to: Lightning Hubs Will Need To Report To IRS COMPLEXITY All cryptocurrencies are complicated for the common person. You may be tech savvy enough to find a secure wallet and use cryptocurrencies, but the masses are not as tech savvy as you. LN adds a very complicated and convoluted layer to cryptocurrencies. It is bound to have bugs for years to come and it’s complicated to use. This article provides a good explanation of the complexity. Just from the screenshot of the app, the user now needs to learn additional terms and commands: “On Chain” “In Channels” “In Limbo” “Your Channel” “Create Channel” “CID” “OPENING” “PENDING-OPEN” “Available to Receive” “PENDING-FORCE-CLOSE” There are also other things to learn, such as how funds need to be allocated to channels and time locks. Compare this to using your current wallet. Recently, LN became even more complicated and convoluted. It needs a 3rd layer as well: Scaling Bitcoin Might Require A Whole 'Nother Layer How many additional steps does a user need to learn? ALL COINS PLANNING OFF-CHAIN SCALING ARE AT RISK Bitcoin Segwit, Litecoin, Vertcoin and possibly others (including Bitcoin Cash) are planning to implement LN or layer 2 scaling. Ethereum is planning to use Raiden Network, which is very similar to LN. If the above is true about LN, then the scaling roadmap for these coins is questionable at best, nullified at worst. BLOCKSTREAM'S GAME PLAN IS ON TRACK Blockstream employs several of the lead Bitcoin Core developers. Blockstream has said repeatedly that they want high fees. Quotes and source links can be found here. Why is Blockstream so adamant on small blocks, high fees and off-chain scaling? Small blocks, high fees and slow confirmations create demand for off-chain solutions, such as Liquid. Blockstream sells Liquid to exchanges to move Bitcoin quickly on a side-chain. LN will create liquidity hubs, such as exchanges, which will generate traffic and fees for exchanges. With this, exchanges will have a higher need for Liquid. This will be the main way that Blockstream will generate revenue for its investors, who invested $76 million. Otherwise, they can go bankrupt and die. One of Blockstream’s investors/owners is AXA. AXA’s CEO and Chairman until 2016 was also the Chairman of Bilderberg Group. The Bilderberg Group is run by bankers and politicians (former prime ministers and nation leaders). According to GlobalResearch, Bilderberg Group wants “a One World Government (World Company) with a single, global marketplace…and financially regulated by one ‘World (Central) Bank’ using one global currency.” LN helps Bilderberg Group get one step closer to its goal. Luke-Jr is one of the lead BTC developers in Core/Blockstream. Regulation of BTC is in-line with his beliefs. He is a big believer in the government, as he believes that the government should tax you and the “State has authority from God”. In fact, he has other radical beliefs as well:
it is moral for the government to execute criminals and heretics (non-believers)
According to this video, Luke-Jr was the only person to have ever carried out a 51% attack, to destroy a coin that he did not like.
So, having only large, regulated LN hubs is not a failure for Blockstream/Bilderberg. It’s a success. The title of this article should be changed to: "Lightning Will Fail Or Succeed, Depending On Whether You Are Satoshi Or Blockstream/Bilderberg". SIGNIFICANT ADVANCEMENTS WITH ON-CHAIN SCALING Meanwhile, some coins such as Ethereum and Bitcoin Cash are pushing ahead with on-chain scaling. Both are looking at Sharding. Visa handles 2,000 transactions per second on average. Blockstream said that on-chain scaling will not work. The development teams for Bitcoin Cash have shown significant on-chain scaling: 1 GB block running on testnet demonstrates over 10,000 transactions per second: "we are not going from 1MB to 1GB tomorrow — The purpose of going so high is to prove that it can be done — no second layer is necessary” "Preliminary Findings Demonstrate Over 10,000 Transactions Per Second" "Gigablock testnet initiative will likely be implemented first on Bitcoin Cash” Peter Rizun, Andrew Stone -- 1 GB Block Tests -- Scaling Bitcoin Stanford At 13:55 in this video, Rizun said that he thinks that Visa level can be achieved with a 4-core/16GB machine with better implementations (modifying the code to take advantage of parallelization.) Bitcoin Cash plans to fix malleability and enable layer 2 solutions: The Future of “Bitcoin Cash:” An Interview with Bitcoin ABC lead developer Amaury Séchet:
"fixing malleability and enabling Layer 2 solutions will happen”
However, it is questionable if layer 2 will work or is needed. GOING FORWARD The four year scaling debate and in-fighting is what caused small blockers (Blockstream) to fork Bitcoin by adding Segwit and big blockers to fork Bitcoin into Bitcoin Cash. Read: Bitcoin Divorce - Bitcoin [Legacy] vs Bitcoin Cash Explained It will be interesting to see how they scale going forward. Scaling will be instrumental in getting network effect and to be widely adopted as a currency. Whichever Coin Has The Most Network Effect Will Take All (Or Most) (BTC has little network effect, and it's shrinking.) The ability to scale will be key to the long term success of any coin.
In the public interest of tracking and remedying cybersecurity vulnerabilities quickly, a public database was created in 2000: the CVE List . CVE stands for Common Vulnerabilities and Exposures. Its database records, known as CVEs, track and record publicly known cybersecurity vulnerabilities. Each recorded vulnerability has a unique ID and lifecycle where it follows certain states.
The AsicBoost controversy
In April 2017, Greg Maxwell published an email  on the bitcoin-dev mailing list which described AsicBoost - a patented optimization to the algorithm used in Bitcoin mining - as an attack on the Bitcoin protocol. There was much contention  about whether AsicBoost constituted some kind of harmful exploit, or whether it was merely a technological innovation which enabled more efficient mining hardware (ASICs). There were allegations, widely reported in media, that the patent served the interest of Bitmain . The purported benefits of exploiting this patent as alleged by Core developers were contemporaneously disputed by other miners .
CVE-2017-9230 raised against AsicBoost
On 18 May 2017, Cameron Garnham posted to the bitcoin-dev list , urging for getting a CVE assigned to the perceived vulnerability. On 24 May 2017, this CVE was created as CVE-2017-9230 . It was simultaneously published under Bugtraq ID 'BID 98657' at . The justification in the CVE stated that the AsicBoost method
'violates the security assumptions of (1) the choice of input, outside of the dedicated nonce area, fed into the Proof-of-Work function should not change its difficulty to evaluate and (2) every Proof-of-Work function execution should be independent.'
It seemed a plausible enough reasoning for the CVE to be assigned. It was entered in the list of Bitcoin-related CVE's at . Detailed information on this particular CVE is still missing/incomplete on the wiki page, a year after the CVE was raised.
What happened since the CVE was raised
If you've followed along, you've learned that the CVE was raised to counter the exploitation of the AsicBoost method by miners. Since then, however, a Core developer, BtcDrak, has been involved in the founding of a mining company, Halong Mining. Several online sources state his (part?) ownership of this company. BtcDrak has put forward a proposal  which would enable the use of AsicBoost within the Bitcoin Core software (the dominant client software on the BTC network). This proposal appears to directly contradict the CVE claims of how AsicBoost violates "security assumptions" of Bitcoin, and indeed does not address how it mitigates them, nor is CVE-2017-9230 referenced in any of its related documentation. While the proposal's specification  and implementation  have not yet been formally accepted, the situation is that Halong has shipped mining equipment which is now actively employing AsicBoost [13,14] on the Bitcoin (BTC) network. There is even a website showing the blocks where AsicBoost was used .
Conflict of interest
There a clear conflict of interest in the actions of the Core developer BtcDrak. His actions as a Core developer appear to be furthering his company's interests and competitive advantage in the mining industry by exploiting a vulnerability of which he must have been keenly aware, having participated on the same bitcoin-dev mailing list where it was discussed. The CVE was vociferously used to paint Bitmain as culpable for delaying Segwit (Bitmain was accused of using AsicBoost and blocking Segwit activation for their own profit motive - claims that Bitmain has publicly denied strongly and which were never substantiated). One might have expected a similar outcry against Halong's proven and announced use of AsicBoost, but the parties that had previously condemned Bitmain remained mostly silent. Only an anonymous non-developer, Cobra-Bitcoin, co-owner of the bitcoin.org domain, spoke out on the Github pull request in , and Core developer Luke-jr spoke out against the use of the proposal on the Bitcoin network while consensus had not been reached on it . Subsequent discussion on the bitcoin-dev list on this topic since March has been minimal and only concerned with technicalities of stratum protocol changes.
The bigger elephant in the room
It seems logical that either AsicBoost constitutes an exploitable weakness, and thus merits a CVE and measures taken to prevent its use on the Bitcoin network entirely. Or it is not a problem and the CVE should be invalidated. The Bitcoin Core project should use its consensus processes to arrive at a coherent decision.
Other problems raised by the use of overt AsicBoost
[Unpopular opinion] They knew they couldn't beat BTC in a hash war, so they went after the Dev team. UnpolularThey knew they couldn't beat the BCH Dev team, so they went with a hash war.
Call me what I am a "conspiracy theorist". But I've seen this shit. I was in a Sonar tech job in the US Navy soon after The Krusk incident and I can tell you, 100% the "official story" is a lie. I have seen the hydrophone recording myself and talked to a guy who were there listening at the time. Bottom line, the US and Russian TOGETHER fucking BLEW UP a nuclear sub with men ON BOARD, to save some top secret info we both didn't want out (PM me for details if you want). Anyway. Do you guys hear me? Our government torpedoed a nuclear submarine killing human beings to essentially save face, lied about it to the world and essentially FORCED the Russians to lie about it too, just a few years ago. That is what is happening, that is the level of this shit, and that was small potatoes. Imagine this similar level of intensity applied to the financial world, do you think we are taking ANY chances with this shit. No. It will be controlled, like it or not. So just choose your master and try to live with it (please never leave us Roger). I hate CSW more than anyone, but he is a useful idiot for someone. Same with u/nullc, Luke-jr, The Toddler, etc. etc. you think these people are the Cream of the Crop? No they are useful idiots, it is why they are where they are, not still living in their homeschooled Mom's basements, jobless. Anyway. Bitcoin is fucked, it was too good to last, we are all fucked. CSW is gonna fucking win, fuck this shit :(
Paper wallets (especially with BIP38) are NOT insecure (at least no more so than the other forms of backup that have been recommend by Luke-Jr). Saying address reuse is the main problem is ridiculous too, because that's a general problem with Bitcoin itself. I could easily make a single address in Bitcoin Core and use it for all my transactions. If the admins on the Bitcoin Wiki aren't going to do something to stop this edit war, then I think we as a community need to break off and start a new wiki. The wiki is the main place for new users to get info on Bitcoin, and including misinformation or information that is only relevant to one person (Luke-Jr) is counter-intuitive to that purpose. Finally, please stop flaming just because this guy is a Christian. It has nothing to do with the stuff that he has been doing and is just simple trolling.
Core/AXA/Blockstream CTO Greg Maxwell, CEO Adam Back, attack dog Luke-Jr and censor Theymos are sabotaging Bitcoin - but they lack the social skills to even feel guilty for this. Anyone who attempts to overrule the market and limit or hard-code Bitcoin's blocksize must be rejected by the community.
AXA is trying to sabotage Bitcoin by paying the most ignorant, anti-market devs in Bitcoin: Core/Blockstream This is the direction that Bitcoin has been heading in since late 2014 when Blockstream started spreading their censorship and propaganda and started bribing and corrupting the "Core" devs using $76 million in fiat provided by corrupt, anti-Bitcoin "fantasy fiat" finance firms like the debt-backed, derivatives-addicted insurance mega-giant AXA. Remember:
Bitcoin was always intended to be upgraded honestly, overtly, explicitly, and transparently - by hard forks as proposed by Satoshi - where you must explicitly "opt in" by deliberately upgrading your code.
Smart, honest devs fix bugs. Fiat-fueled AXA-funded Core/Blockstream devs add bugs - and then turn around and try to lie to our face and claim their bugs are somehow "features" Recently, people discovered bugs in other Bitcoin implementations - memory leaks in BU's software, "phone home" code in AntMiner's firmware. And the devs involved immediately took public responsibility, and fixed these bugs. Meanwhile...
AXA-funded Blockstream's centrally planned blocksize is still a (slow-motion but nonethless long-term fatal) bug, and
AXA-funded Blockstream's Anyone-Can-Spend SegWit hack/kludge is still a poison-pill.
People are so sick and tired of AXA-funded Blockstream's lies and sabotage that 40% of the network is already mining blocks using BU - because we know that BU will fix any bugs we find (but AXA-funded Blockstream will lie and cheat and try to force their bugs down everyone's throats).
So the difference is: BU's and AntMiner's devs possess enough social and economic intelligence to fix bugs in their code immediately when the community finds them. Meanwhile, most people in the community have been in an absolute uproar for years now against AXA-funded Blockstream's centrally planned blocksize and their deadly Anyone-Can-Spend hack/kludge/poison-pill. Of course, the home-schooled fiat-fattened sociopath Blockstream CTO One-Meg Greg u/nullc would probably just dismiss all these Bitcoin users as the "shreaking" [sic] masses. Narcissistic sociopaths like AXA-funded Blockstream CTO Greg Maxwell and CTO Adam and their drooling delusional attack dog Luke-Jr (another person who was home-schooled - which may help explain why he's also such a tone-deaf anti-market sociopath) are just too stupid and arrogant to have the humility and the shame to shut the fuck up and listen to the users when everyone has been pointing out these massive lethal bugs in Core's shitty code. Greg, Adam, Luke-Jr, and Theymos are the most damaging people in Bitcoin These are the four main people who are (consciously or unconsciously) attempting to sabotage Bitcoin:
These toxic idiots are too stupid and shameless and sheltered - and too anti-social and anti-market - to even begin to recognize the lethal bugs they have been trying to introduce into Bitcoin's specification and our community. Users decide on specifications. Devs merely provide implementations. Guys like Greg think that they're important because they can do implemenation-level stuff (like avoiding memory leaks in C++ code). But they are total failures when it comes to specification-level stuff (ie, they are incapable of figuring out how to "grow" a potentially multi-trillion-dollar market by maximally leveraging available technology).
Core/Blockstream is living in a fantasy world. In the real world everyone knows (1) our hardware can support 4-8 MB (even with the Great Firewall), and (2) hard forks are cleaner than soft forks. Core/Blockstream refuses to offer either of these things. Other implementations (eg: BU) can offer both.
https://np.reddit.com/btc/comments/5ejmin/coreblockstream_is_living_in_a_fantasy_world_in/ Greg, Adam, Luke-Jr and Theymos apparently lack the social and economic awareness and human decency to feel any guilt or shame for the massive damage they are attempting to inflict on Bitcoin - and on the world. Their ignorance is no excuse Any dev who is ignorant enough to attempt to propose adding such insidious bugs to Bitcoin needs to be rejected by the Bitcoin community - no matter how many years they keep on loudly insisting on trying to sabotage Bitcoin like this. The toxic influence and delusional lies of AXA-funded Blockstream CTO Greg Maxwell, CEO Adam Back, attack dog Luke-Jr and censor Theymos are directly to blame for the slow-motion disaster happening in Bitcoin right now - where Bitcoin's market cap has continued to fall from 100% towards 60% - and is continuing to drop.
When bitcoin drops below 50%, most of the capital will be in altcoins. All they had to do was increase the block size to 2mb as they promised. Snatching defeat from the jaws of victory.
u/FormerlyEarlyAdopter : "I predict one thing. The moment Bitcoin hard-forks away from Core clowns, all the shit-coins out there will have a major sell-off." ... u/awemany : "Yes, I expect exactly the same. The Bitcoin dominance index will jump above 95% again."
https://np.reddit.com/btc/comments/5yfcsw/uformerlyearlyadopter_i_predict_one_thing_the/ Market volume (ie, blocksize) should be decided by the market - not based on some arbitrary number that some ignorant dev pulled out of their ass For any healthy cryptocurrency, market price and market capitalization and market volume (a/k/a "blocksize") are determined by the market - not by any dev team, not by central bankers from AXA, not by economically ignorant devs like Adam and Greg (or that other useless idiot - Core "Lead Maintainer" Wladimir van der Laan), not by some drooling pathological delusional authoritarian freak like Luke-Jr, and not by some petty tyrant and internet squatter and communmity-destroyer like Theymos. The only way that Bitcoin can survive and prosper is if we, as a community, denounce and reject these pathological "centralized blocksize" control freaks like Adam and Greg and Luke and Theymos who are trying to use tricks like fiat and censorship and lies (in collusion with their army of trolls organized and unleashed by the Dragons Den) to impose their ignorance and insanity on our currency. These losers might be too ignorant and anti-social to even begin to understand the fact that they are attempting to sabotage Bitcoin. But their ignorance is no excuse. And Bitcoin is getting ready to move on and abandon these losers. There are many devs who are much better than Greg, Adam and Luke-Jr A memory leak is an implementation error, and a centrally planned blocksize is a specification error - and both types of errors will be avoided and removed by smart devs who listen to the community. There are plenty of devs who can write Bitcoin implementations in C++ - plus plenty of devs who can write Bitcoin implementations in other languages as well, such as:
Greg, Adam, Luke-Jr and Theymos are being exposed as miserable failures AXA-funded Blockstream CTO Greg Maxwell, CEO Adam Back, their drooling attack dog Luke-Jr and their censor Theymos (and all the idiot small-blockheads, trolls, and shills who swallow the propaganda and lies cooked up in the Dragons Den) are being exposed more and more every day as miserable failures. Greg, Adam, Luke-Jr and Theymos had the arrogance and the hubris to want to be "trusted" as "leaders". But Bitcoin is the world's first cryptocurrency - so it doesn't need trust, and it doesn't need leaders. It is decentralized and trustless. C++ devs should not be deciding Bitcoin's volume. The market should decide. It's not suprising that a guy like "One-Meg Greg" who adopts a nick like u/nullc (because he spends most of his life worrying about low-level details like how to avoid null pointer errors in C++ while the second-most-powerful fiat finance corporation in the world AXA is throwing tens of millions of dollars of fiat at his company to reward him for being a "useful idiot") has turned to be not very good at seeing the "big picture" of Bitcoin economics. So it also comes as no suprise that Greg Maxwell - who wanted to be the "leader" of Bitcoin - has turned out to be one of most harmful people in Bitcoin when it comes to things like growing a potentially multi-trillion-dollar market and economy. All the innovation and growth and discussion in cryptocurrencies is happening everywhere else - not at AXA-funded Blockstream and r\bitcoin (and the recently discovered Dragons Den, where they plan their destructive social engineering campaigns). Those are the censored centralized cesspools financed by central bankers and overrun by loser devs and the mindless trolls who follow them - and supported by inefficient miners who want to cripple Bitcoin with centrally planned blocksize (and dangerous "Anyone-Can-Spend" SegWit). Bitcoin is moving on to bigger blocks and much higher prices - leaving AXA-funded Blockstream's crippled censored centrally planned shit-coin in the dust Let them stagnate in their crippled shit-coin with its centrally planned, artificial, arbitrary 1MB 1.7MB blocksize, and SegWit's Anyone-Can-Spend hackkludge poison-pill. Bitcoin is moving on without these tyrants and liars and losers and sociopaths - and we're going to leave their crippled censored centrally planned shit-coin in the dust.
Core/Blockstream are now in the Kübler-Ross "Bargaining" phase - talking about "compromise". Sorry, but markets don't do "compromise". Markets do COMPETITION. Markets do winner-takes-all. The whitepaper doesn't talk about "compromise" - it says that 51% of the hashpower determines WHAT IS BITCOIN.
Core/Blockstream is living in a fantasy world. In the real world everyone knows (1) our hardware can support 4-8 MB (even with the Great Firewall), and (2) hard forks are cleaner than soft forks. Core/Blockstream refuses to offer either of these things. Other implementations (eg: BU) can offer both.
1 BTC = 64 000 USD would be > $1 trillion market cap - versus $7 trillion market cap for gold, and $82 trillion of "money" in the world. Could "pure" Bitcoin get there without SegWit, Lightning, or Bitcoin Unlimited? Metcalfe's Law suggests that 8MB blocks could support a price of 1 BTC = 64 000 USD
Bitcoin Original: Reinstate Satoshi's original 32MB max blocksize. If actual blocks grow 54% per year (and price grows 1.542 = 2.37x per year - Metcalfe's Law), then in 8 years we'd have 32MB blocks, 100 txns/sec, 1 BTC = 1 million USD - 100% on-chain P2P cash, without SegWit/Lightning or Unlimited
SegWit would make it HARDER FOR YOU TO PROVE YOU OWN YOUR BITCOINS. SegWit deletes the "chain of (cryptographic) signatures" - like MERS (Mortgage Electronic Registration Systems) deleted the "chain of (legal) title" for Mortgage-Backed Securities (MBS) in the foreclosure fraud / robo-signing fiasco
SegWit is a "clever innovation" brought to you by clueless / corrupt AXA-owned Blockstream devs;
MERS is a "clever innovation" brought to you by reckless / corrupt Wall Street bankers;
SegWit and MERS both work by simply deleting crucial "ownership data" for transactions.
Of course, the "experts" (on Wall Street, and at AXA-owned Blockstream) present MERS and SegWit as "innovations" - as a way to "optimize" and "streamline" vast chains of transactions reflecting ownership and transfer of valuable items (ie, real-estate mortgages, and bitcoins). But, unfortunately, the "brilliant bat-shit insane approach" devised by the "geniuses" behind MERS and SegWit to do this is to simply delete the data which proved ownership and transfer of these items - information which is essential for legal purposes (in the case of mortgages), or security purposes (in the case of bitcoins).
SegWit allows deleting the "chain of (cryptographic) signatures" for bitcoins - ie, SegWit supports deleting the cryptographic data specifying "who transmitted what bitcoins to whom" (as originally specified in Satoshi's whitepaper defining Bitcoin);
MERS (Mortgage Electronic Registration Systems) allowed deleting the "chain of (legal) title" for real-estate mortgages - ie, MERS supported deleting the legal "notes" specifying "who transmitted what mortgages to whom" (as previously tracked by banks / mortgage lenders / originators / notaries / land registries / "cadasters", etc.)
So, the most pernicious aspect of SegWit may be that it encourages deleting all of Bitcoin's cryptographic security data - destroying the "chain of signatures" which (according to the white paper) are what define what a "bitcoin" actually is. Wow, deleting signatures with SegWit sounds bad. Can I avoid SegWit? Yes you can. To guarantee the long-term cryptographic, legal and financial security of your bitcoins:
You should avoid sending / receiving / holding Bitcoins using the dangerous, new "SegWit" addresses. (As far as I understand, "SegWit" bitcoin addresses all start with a "3".)
You should just use safe, "normal" Bitcoin addresses - and avoid using unsafe "SegWit" addresses. (If I understand correctly, all "normal" Bitcoin addresses still start with a "1", while "SegWit" addresses always start with a "3".)
You can also use Bitcoin implementations which encourage using "normal" Bitcoin addresses. (As far as I understand, implementations such as Bitcoin ABC, Bitcoin Unlimited, Bitcoin Classic are being deployed mainly to support "normal", "non-SegWit" Bitcoin addresses - as well as market-based (bigger) blocksizes and (lower) fees.)
You can avoid Bitcoin implementations which require SegWit. (As far as I understand, SegWit2x, UASF/BIP148 are being deployed mainly to support "SegWit" Bitcoin addresses - as well as centrally-planned (smaller) blocksizes and (higher) fees).
MERS = "The dog ate your mortgage's chain of title". SegWit = "The dog ate your bitcoin's chain of signatures."
By deleting / losing the "chain of title" for mortgages stored in the MERS database (in the name of "innovation" and "efficiency" and "optimization" being pushed by "clever" bankers on Wall Street), MERS caused a legal and financial catastrophe for mortgages - by making it impossible to (legally) prove who owns which properties.
By deleting / losing the "chain of signatures" for Bitcoins stored in SegWit addresses (in the name of "innovation" and "efficiency" and "optimization" being pushed by "clever" devs at AXA-owned Blockstream), SegWit could end up causing a financial (and possibly also legal) catastrophe for Bitcoin - by making it impossible (or at least more complicated in many cases) to (cryptographically) prove who owns which bitcoins.
Wall Street-backed MERS = AXA-backed SegWit It is probably no coincidence that:
Clueless, corrupt bankers from Wall Street used MERS to recklessly delete the "chain of (legal) title" for people's mortgages;
And now clueless, corrupt devs from AXA-owned Blockstream want to recklessly use SegWit to delete the "chain of (cryptographic) signatures" for people's bitcoins.
by supporting the most ignorant developers and "leaders" (lying Blockstream CTO Greg Maxwell and CEO Adam Back, drooling authoritarian idiot Luke-Jr, vandal Peter Todd, etc);
by supporting a massive campaign of propaganda, censorship, and lies (on forums like r\bitcoin and sites like bitcointalk.org - both controlled by the corrupt censor u/Theymos) to try to force SegWit on the Bitcoin community.
Do any Core / Blockstream devs and supporters know about MERS - and recognize its dangerous parallels with SegWit? It would be interesting to hear from some of the "prominent" Core / Blockstream devs and supporters listed below to find out if they are aware of the dangerous similarities between SegWit and MERS:
Luke-Jr u/luke-jr - co-founder of and occasional contractor for Blockstream, in charge of Core's "BIP" numbering process, known for his [delusions] and authoritarianism - and for the messy SegWit-as-a-soft-fork kludge - now leading the brainwashed lemmings and sybils of r\bitcoin off the cliff, with his doomed UASF/BIP148;
Core / Blockstream devs might not know about MERS - but AXAdefinitely does While it is likely that most or all Core / Blockstream devs do not know about the MERS fiasco... ...it is 100% certain that people at AXA (the main owners of Blockstream) do know about MERS. This is because the global financial crisis which started in 2008 was caused by:
CDOs - collateralized debt obligations
MBSs - mortgage-backed securities
MERS - the company / database Mortgage Electronic Registration Systems which "lost" (deleted) millions of people's mortgage notes - leading to "clouded titles" which made possible the wave of foreclosure fraud and robo-signing, which eventually cost the "clever" banks tens of billions of dollars in losses.
Loans originated with MERS as the original mortgagee purport to separate the borrower’s promissory note, which is made payable to the originating lender, from the borrower’s conveyance of a mortgage, which purportedly is granted to MERS. If this separation is legally incorrect - as every state supreme court looking at the issue has agreed - then the security agreements do not name an actual mortgagee or beneficiary. The mortgage industry, however, has premised its proxy recording strategy on this separation, despite the U.S. Supreme Court’s holding that “the note and mortgage are inseparable.” [Compare with the language from Satoshi's whitepaper: "We define an electronic coin as a chain of digital signatures."] If today’s courts take the Carpenter decision at its word, then what do we make of a document purporting to create a mortgage entirely independent of an obligation to pay? If the Supreme Court is right that a “mortgage can have no separate existence” from a promissory note, then a security agreement that purports to grant a mortgage independent of the promissory note attempts to convey something that cannot exist. [...] Many courts have held that a document attempting to convey an interest in realty fails to convey that interest if the document does not name an eligible grantee. Courts around the country have long held that “there must be, in every grant, a grantor, a grantee and a thing granted, and a deed wanting in either essential is absolutely void.”
The parallels between MERS and SegWit are obvious and inescapable.
MERS separated (and eventually deleted) the legal information regarding the "conveyance" (transfer) of ownership of "realty" (real estate)
SegWit segregates (and allows eventually deleting) the cryptographic information regarding the sending and receiving of bitcoins.
Note that I am not arguing here that SegWit could be vulnerable to attacks from a strictly legal perspective. (Although that may be possible to.) I am simply arguing that SegWit, because it encourages deleting the (cryptographic) signature data which defines "bitcoins", could eventually be vulnerable to attacks from a cryptographic perspective. But I heard that SegWit is safe and tested! Yeah, we've heard a lot of lies from Blockstream, for years - and meanwhile, they've only succeeded in destroying Bitcoin's market cap, due to unnecessarily high fees and unnecessarily slow transactions. Now, in response to those legal-based criticisms of SegWit in the article from nChain, several so-called "Bitcoin legal experts" have tried to rebut that those arguments from nChain were somehow "flawed". But if you read the rebuttals of these "Bitcoin legal experts", they sound a lot like the clueless "experts" who were cheerleading MERS for its "efficiency" - and who ended up costing tens billions of dollars in losses when the "chain of title" for mortgages held in the MERS database became "clouded" after all the crucial "ownership data" got deleted in the name of "efficiency" and "optimization". In their attempt to rebut the article by nChain, these so-called "Bitcoin legal experts" use soothing language like "optimization" and "pragmatic" to try to lull you into believing that deleting the "chain of (cryptographic) signatures" for your bitcoins will be just as safe as deleting the "chain of (legal) notes" for mortgages: http://www.coindesk.com/bitcoin-legal-experts-nchain-segwit-criticisms-flawed/ The (unsigned!) article on CoinDesk attempting to rebut Nguyen's article on nChain starts by stating:
Nguyen's criticisms fly in the face of what has emerged as broad support for the network optimization, which has been largely embraced by the network's developers, miners and startups as a pragmatic step forward.
Then it goes on to quote "Bitcoin legal experts" who claim that using SegWit to delete Bitcoin's cryptographic signatures will be just fine:
Marco Santori, a fintech lawyer who leads the blockchain tech team at Cooley LLP, for example, took issue with what he argued was the confused framing of the allegation. Santori told CoinDesk:
"It took the concept of what is a legal contract, and took the position that if you have a blockchain signature it has something to do with a legal contract."
Stephen Palley, counsel at Washington, DC, law firm Anderson Kill, remarked similarly that the argument perhaps put too much weight on the idea that the "signatures" involved in executing transactions on the bitcoin blockchain were or should be equivalent to signatures used in digital documents.
"It elides the distinction between signature and witness data and a digital signature, and they're two different things," Palley said.
"There are other ways to cryptographically prove a transaction is correctly signed other than having a full node," said BitGo engineer Jameson Lopp. "The assumption that if a transaction is in the blockchain, it's probably valid, is a fairly good guarantee." Legal experts asserted that, because of this design, it's possible to prove that the transaction occurred between parties, even if those involved did not store signatures. For this reason, Coin Center director Jerry Brito argued that nChain is overstating the issues that would arise from the absence of this data. "If you have one-time proof that you have the bitcoin, if you don't have it and I have it, logically it was signed over to me. As long as somebody in the world keeps the signature data and it's accessible, it's fine," he said.
There are several things you can notice here:
These so-called "Bitcoin legal experts" are downplaying the importance of signatures in Bitcoin - just like the "experts" behind MERS downplayed the importance of "notes" for mortgages.
Satoshi said that a bitcoin is a "chain of digital signatures" - but these "Bitcoin legal experts" are now blithely asserting that we can simply throw the "chain of digital signatures" in the trash - and we can be "fairly" certain that everything will "probably" be ok.
The "MERS = SegWit" argument which I'm making is not based on interpreting Bitcoin signatures in any legal sense (although some arguments could be made along those lines).
Instead, I'm just arguing that any "ownership database" which deletes its "ownership data" (whether it's MERS or SegWit) is doomed to end in disaster - whether that segregated-and-eventually-deleted "ownership data" is based on law (with MERS), or cryptography (with SegWit).
Who's right - Satoshi or the new "Bitcoin experts"? You can make up your own mind. Personally, I will never send / receive / store large sums of money using any "SegWit" bitcoin addresses. This, is not because of any legal considerations - but simply because I want the full security of "the chain of (cryptographic) signatures" - which, according to the whitepaper, is the very definition of what a bitcoin "is". Here are the words of Satoshi, from the whitepaper, regarding the "chain of digital signatures": https://www.bitcoin.com/bitcoin.pdf
We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.
Does that "chain of digital signatures" sound like something you'd want to throw in the trash??
The "clever devs" from AXA-owned Blockstream (and a handful of so-called "Bitcoin legal experts) say "Trust us, it is safe to delete the chain of signatures proving ownership and transfer of bitcoins". They're pushing "SegWit" - the most radical change in the history of Bitcoin. As I have repeatedly discussed, SegWit weakens Bitcoin's security model.
The people who support Satoshi's original Bitcoin (and clients which continue to implement it: Bitcoin ABC, Bitcoin Unlimited, Bitcoin, Bitcoin Classic - all supporting "Bitcoin Cash" - ie "Bitcoin" without SegWit) say "Trust no one. You should never delete the chain of signatures proving ownership and transfer of your bitcoins."
We define an electronic coin as a chain of digital signatures.
So, according to Satoshi, a "chain of digital signatures" is the very definition of what a bitcoin is.
Meanwhile according to some ignorant / corrupt devs from AXA-owned Blockstream (and a handful of "Bitcoin legal experts") now suddenly it's "probably" "fairly" safe to just throw Satoshi's "chain of digital signatures" in the trash - all in the name of "innovation" and "efficiency" and "optimization" - because they're so very clever.
Who do you think is right? Finally, here's another blatant lie from SegWit supporters (and small-block supporters) Let's consider this other important quote from Satoshi's whitepaper above:
A payee can verify the signatures to verify the chain of ownership.
Remember, this is what "small blockers" have always been insisting for years. They've constantly been saying that "blocks need to be 1 MB!!1 Waah!1!" - even though several years ago the Cornell study showed that blocks could already be 4 MB, with existing hardware and bandwidth. But small-blockers have always insisted that everyone should store the entire blockchain - so they can verify their own transactions. But hey, wait a minute! Now they turn around and try to get you to use SegWit - which allows deleting the very data which insisted that you should download and save locally to verify your own transactions! So, once again, this exposes the so-called "arguments" of small-blocks supporters as being fake arguments and lies:
On the one hand, they (falsely) claim that small blocks are necessary in order for everyone to be run "full nodes" because (they claim) that's the only way people can personally verify all their own transactions. By the way, there are already several errors here with what they're saying:
Actually "full nodes" is a misnomer (Blockstream propaganda). The correct terminology is "full wallets", because only miners are actually "nodes".
Actually 1 MB "max blocksize" is not necessary for this. The Cornell study showed that we could easily be using 4 MB or 8 MB blocks by now - since, as everyone knows, the average size of most web pages is already over 2 MB, and everyone routinely downloads 2 MB web pages in a matter of seconds, so in 10 minutes you could download - and upload - a lot more than just 2 MB. But whatever.
On the other hand, they support SegWit - and the purpose of SegWit is to allow people to delete the "signature data".
This conflicts with their argument the everyone should personally verify all their own transactions. For example, above, Coin Center director Jerry Brito was saying: "As long as somebody in the world keeps the signature data and it's accessible, it's fine."
So which is it? For years, the "small blockers" told us we needed to all be able to personally verify everything on our own node. And now SegWit supporters are telling us: "Naah - you can just rely on someone else's node."
Plus, while the transactions are still being sent around on the wire, the "signature data" is still there - it's just "segregated" - so you're not getting any savings on bandwidth anyways - you'd only get the savings if you delete the "signature data" from storage.
Storage is cheap and plentiful, it's never been the "bottleneck" in the system. Bandwidth is the main bottleneck - and SegWit doesn't help that at all, because it still transmits all the data.
Conclusion So if you're confused by all the arguments from small-blockers and SegWitters, there's a good reason: their "arguments" are total bullshit and lies. They're attempting to contradict and destroy:
Satoshi's original design of Bitcoin as a "chain of digital signatures":
"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership."
Satoshi's plan for scaling Bitcoin by simply increasing the goddamn blocksize:
Satoshi Nakamoto, October 04, 2010, 07:48:40 PM "It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit / It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete."
The the notorious mortgage database MERS, pushed by clueless and corrupt Wall Street bankers, deleted the "chain of (legal) title" which had been essential to show who conveyed what mortgages to whom - leading to "clouded titles", foreclosure fraud, and robo-signing.
The notorious SegWit soft fork / kludge, pushed by clueless and corrupt AXA-owned Blockstream devs, allows deleting the "chain of (cryptographic) signatures" which is essential to show who sent how many bitcoins to whom - which could lead to a catastrophe for people who foolishly use SegWit addresses (which can be avoided: unsafe "SegWit" bitcoin addresses start with a "3" - while safe, "normal" Bitcoin addresses start with a "1").
Stay safe and protect your bitcoin investment: Avoid SegWit transactions.
[See the comments from me directly below for links to several articles on MERS, foreclosure fraud, robo-signing, "clouded title", etc.]
Chaine d'information Sans Limites TV éditée par le Groupe GSL Communication, Ouest Foire Dakar ( Sénégal ) Directeur de Publication : Yankhoba SANE SERVICE C... UPDATES: http://bit.ly/2WxOemI Watch Part 2 Here: https://youtu.be/WZAbJOYsQqQ Absolutely terrifying. This one was not fun to make at all. Everything was pro... Sign up for Brilliant for free at http://Brilliant.org/HAI The first 200 to use that link will also get 20% off their annual premium subscription Get a Half ... Gossip Room est une communauté sur les réseaux sociaux, créée il y a 7 ans, qui regroupe aujourd’hui des millions de passionnés d’actualité TV, people, série... The Remain argument is over, washed away in a million tears of unfathomable middle-class sadness. Follow me on Bitchute: https://www.bitchute.com/profile/JnQ...