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.)
And since on Bitcoin.org there's now one wallet less, Luke-Jr is proposing to add his Bitcoin LJR. Among the fantastic feature set: support for tonal notation, and enhanced spam filters. As usual. Another normal day on Thermo-Blockstream land...
I can't believe I'm saying this, but Luke Jr is right - low fee tx's will never get processed under the new RBF rules and user bitcoins will be in limbo until they upgrade to a wallet that supports RBF
03-23 19:33 - 'I absolutely recommend everyone do never use this wallet, this wallet has not been vetted for and luke-jr is a known scammer: [link]' by /u/Waterwaterdude555 removed from /r/Bitcoin within 109-119min
And since on Bitcoin.org there's now one wallet less, Luke-Jr is proposing to add his Bitcoin LJR. Among the fantastic feature set: support for tonal notation, and enhanced spam filters. As usual. Another normal day on Thermo-Blockstream land...
I can't believe I'm saying this, but Luke Jr is right - low fee tx's will never get processed under the new RBF rules and user bitcoins will be in limbo until they upgrade to a wallet that supports RBF
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.
WARNING: If you try to use the Lightning Network you are at extremely HIGH RISK of losing funds and is not recommended or safe to do at this time or for the foreseeable future (274 points, 168 comments)
The guy who won this week's MillionaireMakers drawing has received ~$55 in BCH and ~$30 in BTC. It will cost him less than $0.01 to move the BCH, but $6.16 (20%) in fees to move the BTC. (164 points, 100 comments)
Do you think Bitcoin needs to increase the block size? You're in luck! It already did: Bitcoin BCH. Avoid the upcoming controversial BTC block size debate by trading your broken Bitcoin BTC for upgraded Bitcoin BCH now. (209 points, 194 comments)
Master list of evidence regarding Bitcoin's hijacking and takeover by Blockstream (185 points, 113 comments)
PSA: BTC not working so great? Bitcoin upgraded in 2017. The upgraded Bitcoin is called BCH. There's still time to upgrade! (185 points, 192 comments)
This sub is the only sub in all of Reddit that allows truly uncensored discussion of BTC. If it turns out that most of that uncensored discussion is negative, DON'T BLAME US. (143 points, 205 comments)
211 points: fireduck's comment in John Mcafee on the run from IRS Tax Evasion charges, running 2020 Presidential Campaign from Venezuela in Exile
203 points: WalterRothbard's comment in I am a Bitcoin supporter and developer, and I'm starting to think that Bitcoin Cash could be better, but I have some concerns, is anyone willing to discuss them?
163 points: YourBodyIsBCHn's comment in I made this account specifically to tip in nsfw/gonewild subreddits
161 points: BeijingBitcoins's comment in Last night's BCH & BTC meetups in Tokyo were both at the same restaurant (Two Dogs). We joined forces for this group photo!
156 points: hawks5999's comment in You can’t make this stuff up. This is how BTC supporters actually think. From bitcoin: “What you can do to make BTC better: check twice if you really need to use it!” 🤦🏻♂️
155 points: lowstrife's comment in Steve Wozniak Sold His Bitcoin at Its Peak $20,000 Valuation
151 points: kdawgud's comment in The government is taking away basic freedoms we each deserve
147 points: m4ktub1st's comment in BCH suffered a 51% attack by colluding miners to re-org the chain in order to reverse transactions - why is nobody talking about this? Dangerous precident
147 points: todu's comment in Why I'm not a fan of the SV community: My recent bill for defending their frivolous lawsuit against open source software developers.
It was unethically conducted: A VC created a private and closed meeting with his investments in the Bitcoin space and a few others without public input; and they made an agreement to forcefully change the rules of Bitcoin. Hello Etherum Foundation (Ironic that the same person was the big driver on ethereum classic). They claim that "core devs" were "invited" but this is misleading enough to be an outright lie: We were asked to add our names to an already completed statement with a dozen other parties names already on it (so, so much for getting it to say something more sensible). It has been promoted with misleading claims of collaboration and support by Bitcoin Core folks, which are just untrue.
It's unspecified. The actual signers of the agreement clearly disagree about what they actually agreed to. While "segwit+2mb" may sound like it means something to you-- it doesn't mean much. Under that banner you could do something fairly reasonable or something terrible [Fairly reasonable, for example would be to activate segwit, then with a reasonable timeframe hardfork to account for scriptSig data the same way that witness data is accounted for]. The details matter. Critically. Perhaps this was partially as a result of forming their agreement without a single participant with ANY experience in Bitcoin consensus rule design-- they didn't even know what you need to know about a protocol change.
Its time-frame is extremely absurd. Actually, absurd doesn't do it justice which is why between that and number #1 several engineers have been just responding "LOL" to the proposal. They don't set any time for design review and analysis, they don't set any time for writing a specification (they don't have one and don't appear to intend to have one), they set aside two weeks for testing-- which is less time than even minor releases of Bitcoin get (and need!) even when they were comprised of small fixes which had mostly existed for months already. They don't allot any time for alternative implementations to implement it (which is especially bad because they can provide useful design feedback). They don't set aside time for meaningful deployment by users (some of whom may have their own lengthy patching and qualification process). They don't seem to have any concern about how forced upgrades erode decentralization and privileged hosted wallets/apis/pools over running your own infrastructure. Basically every stage of the consensus rule change pipeline should take (and always has taken) more time they allotted for everything. BU+Classic BIP109 ran on testnet for months before their interoperability failure was revealed and they forked apart from each other and abandon BIP109.
They are explicitly rejecting and shielding themselves from public comment. E.g. they created a lf mailing list but when Luke-jr tried to join it Jeff replied saying the list was only for people who supported the agreement and intended to support it. Responses to requests to make their system compatible with BIP141 or BIP148 and existing nodes; have just been met with vague hand-waving about the "charter" and deleting comments on their github. This is doubly bad because some of their technical proposals just won't work and will self partition if deployed.
It doesn't answer any of the serious concerns about the negative impact of increased capacity on the viability of the system, it just takes the capacity doubling of segwit (which is already seen by many as pretty extreme) and doubles it again. Some of the signers seemed to believe that what they agreed to was "segwit immediately" which at least would give some walk-before-running time but to the extent that I can figure out what they're doing, it isn't that. Keep in mind that segwit itself was a massive compromise-- taking on a large and risky increase in load, but countering it with scalability improvements... and as soon as it was proposed the goalpost moved. I doubt many see segwit2x as anything else.
Bitcoin's value comes significantly from its durability against change. Bitcoin is fine the way it is-- it could be even better, but it doesn't need to make radical incompatible hasty changes. Everyone who wants cabal-controlled fork-a-week coins have several options to choose from. Bitcoin is never going to be better at being that than the cruddy altcoins which were designed for it (with huge premines to keep those early holders pumping through the waves of technical failure). In a competitive market we should look at what differentiates Bitcoin from the competition and exploit that as much as we can, not try to me-too follow around other things. If Barry and Co can rewrite Bitcoin's rules against non-trivial opposition who else can also do so?
Bitcoin Core doesn't have the technical or moral authority to make incompatible changes to the rules of the network. And the dozens of major individual contributors just do not personally support this proposal (for some of the reasons above or others)-- and are obviously not going to volunteer their efforts to aid a proposal which they believe would harm Bitcoin. Probably this one would be the TLDR: Core isn't a company, it is an open public collaboration of many people. Core won't endorse pretty much anything but it certainly won't endorse things which are widely (or in this case nearly unanimously) opposed by its contributors.
None of the involved parties have showed even the slightest indication that they understood or cared about concerns like the above, even when people like Matt wasted hours trying to communicate them to them. Not a "I understand but we'll account for that by X"-- but just talking to a wall. Which means that its unlikely that the negative consequences of these concerns will be avoided with any reliability.
But finally-- what would be the point? I think that almost any one of these issues alone would make it dead on arrival. I'd say stick a fork in it, but Bitmain already has-- e.g. their post today says they have no intention on following through with segwit2x by saying they'd only activate segwit if it had more modifications (surprise, surprise). The tech community was polite enough to keep most of our concerns in private and wait and see it this transformed into something supportable. But we've started speaking against it since the misleading claims that we supported and were collaborating with it started. Cheers,
This document describes a virtuous combination of James Hilliard’s “Reduced signalling threshold activation of existing segwit deployment”, Shaolin Fry’s “Mandatory activation of segwit deployment”, Sergio Demian Lerner’s “Segwit2Mb” proposal, Luke Dashjr’s “Post-segwit 2 MB block size hardfork”, and hard fork safety mechanisms from Johnson Lau’s “Spoonnet” into a single omnibus proposal and patchset. ...
Proposal Signaling The string “COOP” is included anywhere in the txn-input (scriptSig) of the coinbase-txn to signal compatibility and support. Soft Fork Fast-activation (segsignal): deployed by a "version bits" with an 80% activation threshold BIP9 with the name "segsignal" and using bit 4... [with a] start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout on midnight November 15th 2017 (epoch time 1510704000). This BIP will cease to be active when segwit is locked-in. Flag-day activation (BIP148): While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected... This BIP will be active between midnight August 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not locked-in or activated before epoch time 1501545600. This BIP will cease to be active when segwit is locked-in. While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected. Hard Fork The hard fork deployment is scheduled to occur 6 months after SegWit activates: (HardForkHeight = SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280) For blocks equal to or higher than HardForkHeight, Luke-Jr’s legacy witness discount and 2MB limit are enacted, along with the following Spoonnet-based improvements:
A "hardfork signalling block" is a block with the sign bit of header nVersion is set [Clearly invalid for old nodes; easy opt-out for light wallets]
If the median-time-past of the past 11 blocks is smaller than the HardForkHeight... a hardfork signalling block is invalid.
Child of a hardfork signalling block MUST also be a hardfork signalling block
Hardfork network version bit is 0x02000000. A tx is invalid if the highest nVersion byte is not zero, and the network version bit is not set.
Deployment of the “fast-activation” soft fork is exactly identical to Hilliard’s segsignal proposal. Deployment of the “flag-day” soft fork is exactly identical to Fry’s BIP148 proposal. HardForkHeight is defined as 26280 blocks after SegWit is set to ACTIVE. All blocks with height greater than or equal to this value must adhere to the consensus rules of the 2MB hard fork.
This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. To prevent the risk of building on top of invalid blocks, miners should upgrade their nodes to support segsignal as well as BIP148. The intent of this proposal is to maintain full legacy consensus compatibility for users up until the HardForkHeight block height, after which backwards compatibility is waived as enforcement of the hard fork consensus ruleset begins.
I will expound upon this later, but I support this proposal. Primarily because it includes BIP148 UASF, secondarily because it includes a 2mB blocksize increase, which I support in principle (I am a big blocker but opposed to divergent consensus.)
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.
Hi all. I'm taking the liberty to share some hard-won experience at this point in time.
Some advice for Core and supporters
It's easy to feel resentment at this stage, having done so much work and written so much high-quality code, and yet getting a shitstorm for it. When I was leading the Swedish Pirate Party into the European Parliament, I was gradually getting used to getting a barrage of criticism grenades for everything I did and didn't do every single day, starting with when I did or didn't get out of bed in the morning. It's very hard to explain what this does to your psyche to somebody who hasn't experienced it. Imagine everybody was out to get you, every single day, and giving you high-pitched screaming blame for everything from an orange being round to some Mongolian guy's utter misinterpretation of what you said three years ago. I'm not exaggerating when I say that people could probably snap and go restraining-shirt-insane for much less. But the crucial thing when you're in a leadership position like that, getting criticism for absolutely everything, is to maintain your ability to sort the relevant criticism apart from the back seat drivers who make a living out of complaining but not contributing. You've also got to trust your inner compass of the vision you want to accomplish. From what I can tell, Core has made the common but crucial mistake of isolating itself from the community and taking on an expert attitude toward everybody else in trusting this inner vision compass over external criticism, where Core is somehow right by definition - the development happens as Core wants it, period. This is very dangerous in any open-source / free software project. Other people are just as intelligent and may have considerable experience and ability to evaluate the claims made, and these should - no, must - be taken seriously. To illustrate just one point, let's take a look at Core's scaling solution here, Segregated Witness. When I apply my nontrivial experience in coding and systems design - I started coding 37 years ago - I see these two options for scaling bitcoin near-term: OPTION ONE - Change the blocksize upper limit to two megabytes. One line of code for the constant, about ten LOCs for activation trigger logic. Requires upgrading of a majority server software. OPTION TWO - Introduce Segwit. About 500 lines of new code, of which at least 100 in the hypersensitive consensus code. Requires upgrading a majority of server software and all client/wallet software and client/wallet hardware, especially those needing to pay money to an arbitrary address (as Segwit introduces a new type of address). When proponents of Core's scaling tell me that Option Two here is the better because it's safer, and I try to comprehend that statement, I am either utterly insane or the statement is the equivalent of "black is white and up is down". It's just not completely counter to all experience in software engineering risk management, it's so far out it doesn't reflect sunlight anymore. When I try to understand more and challenge the assertion that option two is safer - on what I must say are very good grounds - I'm told that I should be leaving design to the experts and that I don't understand enough of the complex machine that is bitcoin. I know I am capable of learning complexities, but I am firmly told off from even trying. That's just not how you succeed in maintaining a community. That's not how you make people want to run your code. Of course, people are free to run whatever code they like. But the checks and balances in an open source community is simple: if the leadership for a project builds something different from what people want to run, they will run something else. It's therefore in the interest of the leadership to listen to the community to understand what software a majority wants to run. These competing interests provide the checks and balances. Now, I understand the complexity of block transfer times through the Chinese firewall and that preliminary tests indicate that a typical full node is saturated at a blocksize of 32 megabytes. However, none of these limits will be hit by this particular scaling. Also, when blazing a trail like this, you work one problem at a time, you solve one bottleneck at a time. People have been flagging for the necessity of increasing the blocksize for ... I don't have dates here at hand, but it should be the better part of a year if not more. Further down the road, scaling node throughput capacity can be done in a number of ways from GPUing ECDSA to specialized hardware, but it's not the imminent bottleneck. When such an enormous amount of crucial data (on the need to raise the blocksize limit) is ignored, that is done at the peril of the project. People in the bitcoin community are intelligent geeks, capable of inhaling absurd amounts of information and cross-referencing all of it. If you are unable to explain why your solution is better than another proposed solution, people will be utterly dissatisfied with the response "because we are the experts" - for you must assume that other people in the community, in the general case, are at least as intelligent and capable of learning as you are. It's even possible that if you can't explain your solution to an open and intelligent mind, it's not a good solution.
Some advice for Classic and supporters
So it appears the hard fork is happening. A lot of people have fought hard to raise the blocksize limit for a long time, using a variety of means, and it seems to be happening at long last. Core didn't take the last available opportunity to include a blocksize limit lift in 0.12, but have announced the release candidate without that feature. So this is it, this is when the fork happens or doesn't happen. Right now, based on announced support, the fork appears to be moving forward. A lot of people supporting Classic are feeling a lot of relief, even if people know that this effort is not done until the blocksize trigger has activated on the network. It's far from there at this point - there's not even deployed code. But everything seems to be going the right way. It's important to reflect on how this is more than a discussion on features. This is an election of what people decide get to decide on the features, direction, quality, and vision moving forward. And as Satoshi declared, there's only one thing determining the outcome of the election: what code is producing the longest chain. That's how bitcoin's democracy works, right there. This is not a selection of features. It's much bigger than that. It's an election of governance and stewardship into the future. As in most elections, there has been a lot of animosity - in both directions. As heels have been dug in, ditches turned to trenches, and preferences turned into prestige, people are starting to call out each other and accuse the other side of not working for what's best for bitcoin, and actively naming specific names in negative contexts. When those in power do this to you, you're feeling everything in the book between resentment, belittling, and outrage. It's easy to do the same thing back. There have even been suggestions that Core is deliberately sabotaging bitcoin to the benefit of ... a selection of actors. This creates a toxic culture leading up to the election point, where people are afraid to take bitcoin-positive initiatives in anticipation of all the negative attention that follows - for in such an environment, practically all attention will be negative. It doesn't help that people incumbent in positions of power tend to "do what they must, because they can" in order to safeguard the status quo, however small or insignificant that incumbency is - this includes everything from Theymos' deletion of discussions, via the silly DDoS attacks on XT nodes, to LukeJR's poison pull request to Classic about killing all miner hardware investment. Actions such as these are not really excusable, but they are still human: people tend to do the very human mistake of letting the ends justify the means, with the ends being what they believe is best for the bitcoin network. Of course, other people disagree of what's best for the bitcoin network, and toxicity follows until the conflict is resolved. And beyond. The toxicity will remain until actively removed by leadership. It is the responsibility of the winner in any rift to end a toxic animosity culture of hostilities and personal adversarialism. I cannot stress this enough. History is full of examples where the winners refused to live alongside the losers and rebuild the world together once the conflict was resolved. It never ends well. On the other hand, where the opposite has been true - South Africa's end of segregation with Mandela as president comes to mind as a good example of leadership here - people learn to put animosity behind them. A lot of people who have submitted code to Core (and previously) are skilled coders, after all, working from their vision. This vision doesn't have to be incompatible with Classic's vision in the slightest - it may just be a matter of slightly different feature priorities, with people intending to get everything in there anyway. (I'd also therefore like to praise Jonathan Toomim for not engaging in the rifting but focusing on solving the problem to most people's acceptance. Real MVP right there.)
Finally, some personal reflections
Unfortunately, I believe bitcoin development has lost touch with large-scale rollout necessities over the past year or so. At the moment, there are three use cases which all new features should seek to improve: Remittance. The act of sending money between individuals in different countries. Drop-in credit card replacement, from the perspectives of both the payer and the merchant (two different use cases). This means that a payment must be instant, easy, and much cheaper than a credit card settlement. These three use cases must be front left, right, and center when doing any design on the bitcoin network, as far as I'm concerned. They also reinforce each other when funds received by remittance don't have to go via fiat to be used for purchasing something. If there's no profit to be made in using bitcoin as a drop-in replacement for credit card payments, bitcoin will not be deployed at scale. Deployment and outcompeting legacy systems depend entirely on merchant financial gains from rollout. The story begins and ends with this observation. That's why I'm concerned when I'm looking at the features of 0.12. I don't see any features targeting one of these three use cases. Fact is, I see at least one feature severely degrading the drop-in capability of credit card replacement - RBF - and the lack of scaling severely jeopardizing, not to say ultimately removing, the profitability in replacing credit cards. What I see is instead engineering for the sake of engineering. The question of "who's the customer?" seems to have gotten lost in the process. While it's arguable that there's no customer as such in an open source project, there's nevertheless an importance in understanding where the front bowling pins are for a disruptive technology like this - and it's certainly not in the one-time initialization time of starting up a new node. I'd argue that the front bowling pins instead are the three use cases I listed above, and would love to see a stronger focus on tangible use cases moving forward even if people disagree with my choice of cases. Onward and upward. Bitcoin will recover and move on. Let's learn from this experience.
Initially, I liked SegWit. But then I learned SegWit-as-a-SOFT-fork is dangerous (making transactions "anyone-can-spend"??) & centrally planned (1.7MB blocksize??). Instead, Bitcoin Unlimited is simple & safe, with MARKET-BASED BLOCKSIZE. This is why more & more people have decided to REJECT SEGWIT.
Initially, I liked SegWit. But then I learned SegWit-as-a-SOFT-fork is dangerous (making transactions "anyone-can-spend"??) & centrally planned (1.7MB blocksize??). Instead, Bitcoin Unlimited is simple & safe, with MARKET-BASED BLOCKSIZE. This is why more & more people have decided to REJECT SEGWIT. Summary Like many people, I initially loved SegWit - until I found out more about it. I'm proud of my open-mindedness and my initial - albeit short-lived - support of SegWit - because this shows that I judge software on its merits, instead of being some kind of knee-jerk "hater". SegWit's idea of "refactoring" the code to separate out the validation stuff made sense, and the phrase "soft fork" sounded cool - for a while. But then we all learned that:
SegWit-as-a-soft-fork would be incredibly dangerous - introducing massive, unnecessary and harmful "technical debt" by making all transactions "anyone-can-spend";
Pieter Wuille's Segregated Witness and Fraud Proofs (via Soft-Fork!) is a major improvement for scaling and security (and upgrading!)
I am very proud of that initial pro-SegWit post of mine - because it shows that I have always been totally unbiased and impartial and objective about the ideas behind SegWit - and I have always evaluated it purely on its merits (and demerits). So, I was one of the first people to recognize the positive impact which the ideas behind SegWit could have had (ie, "segregating" the signature information from the sender / receiver / amount information) - if SegWit had been implemented by an honest dev team that supports the interests of the Bitcoin community. However, we've learned a lot since December 2015. Now we know that Core / Blockstream is actively working against the interests of the Bitcoin community, by:
trying to force their political and economic viewpoints onto everyone else by "hard-coding" / "bundling" some random / arbitrary / centrally-planned 1.7MB "max blocksize" (?!?) into our code;
trying to take away our right to vote via a clean and safe "hard fork";
trying to cripple our code with dangerous "technical debt" - eg their radical and irresponsible proposal to make all transactions "anyone-can-spend".
This is the mess of SegWit - which we all learned about over the past year. So, Core / Blockstream blew it - bigtime - losing my support for SegWit, and the support of many others in the community. We might have continued to support SegWit if Core / Blockstream had not implemented it as a dangerous and dirty soft fork. But Core / Blockstream lost our support - by attempting to implement SegWit as a dangerous, anti-democratic soft fork. The lesson here for Core/Blockstream is clear: Bitcoin users are not stupid. Many of us are programmers ourselves, and we know the difference between a simple & safe hard fork and a messy & dangerous soft fork. And we also don't like it when Core / Blockstream attempts to take away our right to vote. And finally, we don't like it when Core / Blockstream attempts to steal functionality away from nodes while using misleading terminology - as u/chinawat has repeatedly been pointing out lately. We know a messy, dangerous, centrally planned hack when we see it - and SegWit is a messy, dangerous, centrally planned hack. If Core/Blockstream attempts to foce messy and dangerous code like SegWit-as-a-soft-fork on the community, we can and should and we will reject SegWit - to protect our billions of dollars of investment in Bitcoin (which could turn into trillions of dollars someday - if we continue to protect our code from poison pills and trojans like SegWit). Too bad you lost my support (and the support of many, many other Bitcoin users), Core / Blockstream! But it's your own fault for releasing shitty code. Below are some earlier comments from me showing how I quickly turned from one of the most outspoken supporters of Segwit (in that single OP I wrote the day I saw Pieter Wuille's presentation on YouTube) - into one of most outspoken opponents of SegWit:
I also think Pieter Wuille is a great programmer and I was one of the first people to support SegWit after it was announced at a congress a few months ago. But then Blockstream went and distorted SegWit to fit it into their corporate interests (maintaining their position as the dominant centralized dev team - which requires avoiding hard-forks). And Blockstream's corporate interests don't always align with Bitcoin's interests.
As noted in the link in the section title above, I myself was an outspoken supporter championing SegWit on the day when I first the YouTube of Pieter Wuille explaining it at one of the early "Scaling Bitcoin" conferences. Then I found out that doing it as a soft fork would add unnecessary "spaghetti code" - and I became one of the most outspoken opponents of SegWit.
Probably the only prominent Core/Blockstream dev who does understand this kind of stuff like the Robustness Principle or its equivalent reformulation in terms of covariant and contravariant types is someone like Pieter Wuille – since he’s a guy who’s done a lot of work in functional languages like Haskell – instead of being a myopic C-tard like most of the rest of the Core/Blockstream devs. He’s a smart guy, and his work on SegWit is really important stuff (but too bad that, yet again, it’s being misdelivered as a “soft-fork,” again due to the cluelessness of someone like Luke-Jr, whose grasp of syntax and semantics – not to mention society – is so glaringly lacking that he should have been recognized for the toxic influence that he is and shunned long ago).
The damage which would be caused by SegWit (at the financial, software, and governance level) would be massive:
Millions of lines of other Bitcoin code would have to be rewritten (in wallets, on exchanges, at businesses) in order to become compatible with all the messy non-standard kludges and workarounds which Blockstream was forced into adding to the code (the famous "technical debt") in order to get SegWit to work as a soft fork.
SegWit was originally sold to us as a "code clean-up". Heck, even I intially fell for it when I saw an early presentation by Pieter Wuille on YouTube from one of Blockstream's many, censored Bitcoin scaling stalling conferences)
But as we all later all discovered, SegWit is just a messy hack.
Probably the most dangerous aspect of SegWit is that it changes all transactions into "ANYONE-CAN-SPEND" without SegWit - all because of the messy workarounds necessary to do SegWit as a soft-fork. The kludges and workarounds involving SegWit's "ANYONE-CAN-SPEND" semantics would only work as long as SegWit is still installed.
This means that it would be impossible to roll-back SegWit - because all SegWit transactions that get recorded on the blockchain would now be interpreted as "ANYONE-CAN-SPEND" - so, SegWit's dangerous and messy "kludges and workarounds and hacks" would have to be made permanent - otherwise, anyone could spend those "ANYONE-CAN-SPEND" SegWit coins!
Segwit cannot be rolled back because to non-upgraded clients, ANYONE can spend Segwit txn outputs. If Segwit is rolled back, all funds locked in Segwit outputs can be taken by anyone. As more funds gets locked up in segwit outputs, incentive for miners to collude to claim them grows.
"SegWit encumbers Bitcoin with irreversible technical debt. Miners should reject SWSF. SW is the most radical and irresponsible protocol upgrade Bitcoin has faced in its history. The scale of the code changes are far from trivial - nearly every part of the codebase is affected by SW" Jaqen Hash’ghar
3 excellent articles highlighting some of the major problems with SegWit: (1) "Core Segwit – Thinking of upgrading? You need to read this!" by WallStreetTechnologist (2) "SegWit is not great" by Deadalnix (3) "How Software Gets Bloated: From Telephony to Bitcoin" by Emin Gün Sirer
"The scaling argument was ridiculous at first, and now it's sinister. Core wants to take transactions away from miners to give to their banking buddies - crippling Bitcoin to only be able to do settlements. They are destroying Satoshi's vision. SegwitCoin is Bankcoin, not Bitcoin" ~ u/ZeroFucksG1v3n
u/Uptrenda on SegWit: "Core is forcing every Bitcoin startup to abandon their entire code base for a Rube Goldberg machine making their products so slow, inconvenient, and confusing that even if they do manage to 'migrate' to this cluster-fuck of technical debt it will kill their businesses anyway."
"SegWit [would] bring unnecessary complexity to the bitcoin blockchain. Huge changes it introduces into the client are a veritable minefield of issues, [with] huge changes needed for all wallets, exchanges, remittance, and virtually all bitcoin software that will use it." ~ u/Bitcoinopoly
Just because something is a "soft fork" doesn't mean it isn't a massive change. SegWit is an alt-coin. It would introduce radical and unpredictable changes in Bitcoin's economic parameters and incentives. Just read this thread. Nobody has any idea how the mainnet will react to SegWit in real life.
Core/Blockstream & their supporters keep saying that "SegWit has been tested". But this is false. Other software used by miners, exchanges, Bitcoin hardware manufacturers, non-Core software developers/companies, and Bitcoin enthusiasts would all need to be rewritten, to be compatible with SegWit
SegWit-as-a-softfork is a hack. Flexible-Transactions-as-a-hard-fork is simpler, safer and more future-proof than SegWit-as-a-soft-fork - trivially solving malleability, while adding a "tag-based" binary data format (like JSON, XML or HTML) for easier, safer future upgrades with less technical debt
ViABTC: "Why I support BU: We should give the question of block size to the free market to decide. It will naturally adjust to ever-improving network & technological constraints. Bitcoin Unlimited guarantees that block size will follow what the Bitcoin network is capable of handling safely."
Bitcoin's specification (eg: Excess Blocksize (EB) & Acceptance Depth (AD), configurable via Bitcoin Unlimited) can, should & always WILL be decided by ALL the miners & users - not by a single FIAT-FUNDED, CENSORSHIP-SUPPORTED dev team (Core/Blockstream) & miner (BitFury) pushing SegWit 1.7MB blocks
The Blockstream/SegWit/LN fork will be worth LESS: SegWit uses 4MB storage/bandwidth to provide a one-time bump to 1.7MB blocksize; messy, less-safe as softfork; LN=vaporware. The BU fork will be worth MORE: single clean safe hardfork solving blocksize forever; on-chain; fix malleability separately.
Brock Pierce's BLOCKCHAIN CAPITAL is part-owner of Bitcoin's biggest, private, fiat-funded private dev team (Blockstream) & biggest, private, fiat-funded private mining operation (BitFury). Both are pushing SegWit - with its "centrally planned blocksize" & dangerous "anyone-can-spend kludge".
The real reason why Core / Blockstream always favors soft-forks over hard-forks (even though hard-forks are actually safer because hard-forks are explicit) is because soft-forks allow the "incumbent" code to quietly remain incumbent forever (and in this case, the "incumbent" code is Core)
Reminder: Previous posts showing that Blockstream's opposition to hard-forks is dangerous, obstructionist, selfish FUD. As many of us already know, the reason that Blockstream is against hard forks is simple: Hard forks are good for Bitcoin, but bad for the private company Blockstream.
"They [Core/Blockstream] fear a hard fork will remove them from their dominant position." ... "Hard forks are 'dangerous' because they put the market in charge, and the market might vote against '[the] experts' [at Core/Blockstream]" - ForkiusMaximus
The proper terminology for a "hard fork" should be a "FULL NODE REFERENDUM" - an open, transparent EXPLICIT process where everyone has the right to vote FOR or AGAINST an upgrade. The proper terminology for a "soft fork" should be a "SNEAKY TROJAN HORSE" - because IT TAKES AWAY YOUR RIGHT TO VOTE.
If Blockstream were truly "conservative" and wanted to "protect Bitcoin" then they would deploy SegWit AS A HARD FORK. Insisting on deploying SegWit as a soft fork (overly complicated so more dangerous for Bitcoin) exposes that they are LYING about being "conservative" and "protecting Bitcoin".
"We had our arms twisted to accept 2MB hardfork + SegWit. We then got a bait and switch 1MB + SegWit with no hardfork, and accounting tricks to make P2SH transactions cheaper (for sidechains and Lightning, which is all Blockstream wants because they can use it to control Bitcoin)." ~ u/URGOVERNMENT
u/Luke-Jr invented SegWit's dangerous "anyone-can-spend" soft-fork kludge. Now he helped kill Bitcoin trading at Circle. He thinks Bitcoin should only hard-fork TO DEAL WITH QUANTUM COMPUTING. Luke-Jr will continue to kill Bitcoin if we continue to let him. To prosper, BITCOIN MUST IGNORE LUKE-JR.
Normal users understand that SegWit-as-a-softfork is dangerous, because it deceives non-upgraded nodes into thinking transactions are valid when actually they're not - turning those nodes into "zombie nodes". Greg Maxwell and Blockstream are jeopardizing Bitcoin - in order to stay in power.
"Negotiations have failed. BS/Core will never HF - except to fire the miners and create an altcoin. Malleability & quadratic verification time should be fixed - but not via SWSF political/economic trojan horse. CHANGES TO BITCOIN ECONOMICS MUST BE THRU FULL NODE REFERENDUM OF A HF." ~ u/TunaMelt
"Anything controversial ... is the perfect time for a hard fork. ... Hard forks are the market speaking. Soft forks on any issues where there is controversy are an attempt to smother the market in its sleep. Core's approach is fundamentally anti-market" ~ u/ForkiusMaximus
As Core / Blockstream collapses and Classic gains momentum, the CEO of Blockstream, Austin Hill, gets caught spreading FUD about the safety of "hard forks", falsely claiming that: "A hard-fork forced-upgrade flag day ... disenfranchises everyone who doesn't upgrade ... causes them to lose funds"
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.
Blockstream is "just another shitty startup. A 30-second review of their business plan makes it obvious that LN was never going to happen. Due to elasticity of demand, users either go to another coin, or don't use crypto at all. There is no demand for degraded 'off-chain' services." ~ u/jeanduluoz
The debate is not "SHOULD THE BLOCKSIZE BE 1MB VERSUS 1.7MB?". The debate is: "WHO SHOULD DECIDE THE BLOCKSIZE?" (1) Should an obsolete temporary anti-spam hack freeze blocks at 1MB? (2) Should a centralized dev team soft-fork the blocksize to 1.7MB? (3) OR SHOULD THE MARKET DECIDE THE BLOCKSIZE?
The Bitcoin community is talking. Why isn't Core/Blockstream listening? "Yes, [SegWit] increases the blocksize but BU wants a literal blocksize increase." ~ u/lurker_derp ... "It's pretty clear that they [BU-ers] want Bitcoin, not a BTC fork, to have a bigger blocksize." ~ u/WellSpentTime
"The MAJORITY of the community sentiment (be it miners or users / hodlers) is in favour of the manner in which BU handles the scaling conundrum (only a conundrum due to the junta at Core) and SegWit as a hard and not a soft fork." ~ u/pekatete
Bitcoin Unlimited is the real Bitcoin, in line with Satoshi's vision. Meanwhile, BlockstreamCoin+RBF+SegWitAsASoftFork+LightningCentralizedHub-OfflineIOUCoin is some kind of weird unrecognizable double-spendable non-consensus-driven fiat-financed offline centralized settlement-only non-P2P "altcoin"
The number of blocks being mined by Bitcoin Unlimited is now getting very close to surpassing the number of blocks being mined by SegWit! More and more people are supporting BU's MARKET-BASED BLOCKSIZE - because BU avoids needless transaction delays and ultimately increases Bitcoin adoption & price!
I have just been banned for from /Bitcoin for posting evidence that there is a moderate/strong inverse correlation between the amount of Bitcoin Core Blocks mined and the Bitcoin Price (meaning that as Core loses market share, Price goes up).
The main difference between Bitcoin core and BU client is BU developers dont bundle their economic and political opinions with their code
https://np.reddit.com/btc/comments/5v3rt2/the_main_difference_between_bitcoin_core_and_bu/ TL;DR: You wanted people like me to support you and install your code, Core / Blockstream? Then you shouldn't have a released messy, dangerous, centrally planned hack like SegWit-as-a-soft-fork - with its random, arbitrary, centrally planned, ridiculously tiny 1.7MB blocksize - and its dangerous "anyone-can-spend" soft-fork semantics. Now it's too late. The market will reject SegWit - and it's all Core / Blockstream's fault. The market prefers simpler, safer, future-proof, market-based solutions such as Bitcoin Unlimited.
Wallet Reviews; Menu × ACA News. Bitcoin ... Exchange Reviews; Wallet Reviews; luke-jr Auto Added by WPeMatico. Home » luke-jr. Jan 1 2020. Veriblock Captured Close to 60% of BTC’s OP Return Transactions in 2019 – Bitcoin News. Anchor Data, BCH, Bitcoin, Bitcoin Cash, btc, ... Luke-jr Warns of SegWit2x ‘Distraction’ In a blog post published Saturday, Luke-jr highlights the technical differences SegWit2x represents while warning of its potentially dangerous implications:. Overall, Segwit2x seems to have one real purpose: to try to stall Segwit longer. […] It is a distraction from the upcoming BIP148 softfork, which is already irreversibly deployed to the network. Meanwhile, beyond the realm of fiction, Bitcoin investors may yet see a reversal of fortunes around the time of Luke-jr’s would-be $50,000 activation date of April 1, 2020. As Bitcoinist reported, momentum is building around a theory that the Bitcoin block reward halving, set for May that year, will begin to push up the Bitcoin price a year in advance. Somehow i have a feeling luke-jr is not really innocent... level 1. 3 points · 1 year ago. But Luke works for Blockstream, and Blockstream is evil. /s. level 2. Comment deleted by user 1 year ago. Continue this thread level 1. 4 points · 1 year ago. Samourai is a great wallet. This is very unfortunate and childish of him. level 2. 5 points · 1 year ago. Samourai is a great wallet. no, they ... Bitcoin Dev Luke Jr: Mixing Bitcoins is Money Laundering, and it's Illegal, also Tax Evasion is a Sin. Use of Bitcoin Nor Free Speech is a Right. - gist:5803075
Bitcoin Chainsplit: Segwit2x, Replay Protection, and Security Risks
Bitcoin Core Dev "Luke-jr" is asked why he is interested in Bitcoin. This is one of the main people in charge of Bitcoin right now. Interview with Bitcoin Core Developer Luke-Jr (@LukeDashjr) Included in the conversation Gibus, MrHodl, and others. What follows is an informal chat about the upcoming Bitcoin chain split in ... (See Part 2 also.) Luke-jr is one of the main developers for Bitcoin right now. "By the way, the Sun really orbits the Earth, not vice-versa." -luke-jr http:... https://itunes.apple.com/us/app/bitcoin-of-america-wallet/id1448496720 Bitcoin wallets are very similar to regular, everyday wallets. Used to carry cash, car... Bitcoin Core developer Luke Dash, Jr. shares the surprising story of how he first learned of Bitcoin. See more at coindesk.com/bitcoin-at-10