SegWit and technologies built on it are grossly oversold

Like all good lies, there is a kernel of truth behind them. However, like all good lie, they omit or distort some specific information which are key. Like all good lie, they get repeated so often that they may end up looking like truth. Let’s go over some of them.

SegWit solves malleability

SegWit only solve malleability for transaction which spend ONLY SegWit UTXO. All other transactions remains malleable. This fix is enough to enable technologies like Lightning network. This comes at the cost of reduced fungibility, because only some coins can be locked in the lighting network.

SegWit solves quadratic hashing

SegWit solves quadratic hashing for some specific transactions just like it solves malleability for some specific transactions. However, quadratic hashing is an attack vector and solving it in some specific case is about as useful as being partially on birth control: none at all. SegWit absolutely fails to solve anything related to quadratic hashing.

SegWit allows blocks up to 4MB

That is technically true. However, while block can be up to 4MB, this is not really what people require bigger block were asking for. To illustrate, let’s imagine your friend got a kid and tells you he needs a bigger car than his 2 seaters. How do you think he will react when you propose him a car that is twice as big, but still only has 2 seats? Well that’s what some are trying to sell to you.

Considering current usages, we can estimate that SegWit will increase the amount of transaction which can be processed by a factor of 1.7x to 2x. The fact that SegWit allows blocks up to 4MB while delivering only a 2X capacity increase is not something to be proud of. It adds a new attack vector, as one could start producing bloated blocks and ultimately reduce the long term scaling capability because the adversarial case just got twice as bad.

People do not want bigger blocks for the sake of bigger blocks, but for the value they bring to users just like people do not want bigger car for the sake of bigger car but because they can transport more people or stuff in it.

Lightning network can go world scale

Lightning network, or in short LN, is a technology which allow users to lock funds into a channel, then do transactions offchain and only settle the end result in the blockchain. This is all great until you look at the fine prints, which are for some reason always omitted.

The first one is that is changes the security model. With LN, the person you are transacting with can steal your funds at any time and it is up to you to publish a proof that you are being stolen from, within a given time frame. This is a drawback in itself, but something one could work with considering the benefit brought by LN. However, in the case where the chain is running at capacity, it may be very expensive, or even not possible at all for you to publish the proof within the required timeframe. In the world of LN, full blocks equals stealing.

The second problem is that it require an ungodly amount of capital to operate. If you want to be able to pay up to $100 using LN, you need to have $100 or more locked into a channel. If you want to be able to receive $100 , this amount or more needs to be locked on the opposite side of the channel. If we imagine an extremely centralized network with only one hub in the middle, processing payments for 10 millions users (which is the order of magnitude of the number of Bitcoin users today) and allow these users to send payments up to $100 , the users collectively would have to lock up at least $1B in channels, and the hub itself would have to also lock $1B in all the channels with its users, and yet, be less useful because of the $100 limit. Yes, that’s $1B, to create a LN the size of the current Bitcoin network. Growing to a billion users and up to $1000 in payments require a trillion dollars from the hub.

But we imagine we won’t have one giant hub, instead we will have several hubs interconnected with each others. Let’s imagine we can find routes for Alice to send a payment to Bob in an average of 3 hops, then we need to have the amount Alice’s send to Bob or more locked up in each channel along the way. The inevitable conclusion is that LN strongly incentivize centralization as longer routes require operators to lock up even more fund that in the centralized scenario.

Schnorr signatures will provide addition capacity

Schnorr signatures are very cool and are indeed both cheaper to validate than currently used ECDSA, and are also more compact, so you can fit more of them in a block. However, signatures go into the witness section of the block, and, with current use cases, and if we keep the same block size limit, the expected witness usage is of about 1MB when it is possible to have up to 3MB of witness data in a SegWit block. As a result, Schnorr cannot deliver any extra capacity because it is optimizing the wrong thing.

Conclusion

When someone is lying continuously to you to sell their tech, rely on censorship, be sure they have ulterior motives. Do not buy or you’ll get scammed.

29 thoughts on “SegWit and technologies built on it are grossly oversold

  1. Wow. Another remarkably dishonest article from the authors of Bitcoin Unlimited. (http://archive.is/5cim0 Archive link)

    > because only some coins can

    Making your transactions non-malleable is a thing you always opt-into because some forms of mallability are an intentional and useful feature. With a segwit using wallet you get non-malleability by default, you can choose to not have it by using things like sighash flags. Obviously if you don’t use a segwit wallet you don’t get the segwit benefit. There is no fungiblity interaction here– any coin can be sent to a segwit wallet and any coins in a segwit wallet can be sent to any other wallet, so that claim is simply untrue.

    > SegWit absolutely fails to solve anything related to quadratic hashing.

    Again, a complete untruth. Segwit makes transaction hashing strictly linear in the size of the transaction. There is no quadratic component at all, and the hashing CPU time for all transactions with multiple inputs is significantly reduced. Because segwit is backward compatible it doesn’t change older transactions (and couldn’t, without risking confiscating funds) but that is okay because segwit doesn’t increase the capacity for older transactions.

    > It adds a new attack vector,

    Dishonest miners being able to make malicious blocks that bloat the system isn’t a new attack, but segwit makes the attack better by reducing the much more serious UTXO (https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e#.qofkg369f bloat attack vector).

    I think this point is especially dishonest coming from a BU developer, given that their whole security model is based on a strong assumption that the aggregate behavior of miners is honest. It’s like a guy who sells houses without doorlocks on the basis that people are honest complaining that someone was lowering their security replacing their deadbolt with a combination fingerprint scanner + key lock where the key was somewhat easier to copy.

    > LN strongly incentivize centralization

    The description given there actually argues the opposite. The funds in channels are required based on the number of channels. Lightning designs today are setup to only build channels as a product of payments you’re already making. Using lightning in a “hub like” way requires extra transactions that you never would have made normally. The big advance of lightning over the prior payment channels proposals is specifically that it doesn’t need hubs.

    Recently BU’s “chief scientist” was making exactly the opposite argument based on the same facts: He argued that lightning did not improve scalablity because there would need to be as many channels as users and so when users went up the channel count would go up.

    > full blocks equals stealing

    This isn’t true– blocks are _always_ effectively full and any system where they aren’t is either irrelevant or subject to censorship. Bitcoin’s incentives depend on full blocks (https://medium.com/@bergealex4/bitcoin-is-unstable-without-the-block-size-size-limit-70db07070a5), as well.. Lightning works fine in the presence of full blocks, and moreover lightning is largely orthogonal to segwit.

    > Schnorr cannot deliver any extra capacity

    This is simply untrue. Our construction for schnorr aggregation on top of segwit yields over 24% additional capacity in the limit with two outputs and infinitely many inputs, this number is nearly achieved with realistic numbers of inputs like 10 (which achieves a 24.6% capacity increase).

    So we have each and every point raised in this blog post are untrue, many absurdly so.

    Finally, the untrue claims in this blog post are being plastered all over rBTC but due to actions (https://bitcointalk.org/index.php?topic=1802320.0) by that subreddit’s moderators I am unable to post a counterargument– not just on rbtc– but anywhere on Reddit. Yet they happily scream about far less limiting actions a censorship.

    • This article is so packed with lie and half truth that I’m certainly not going to cover it all. I know you are a smart guy and I know you are knowledgeable about SegWit, so the most evident explanation here is that you are being dishonest on purpose. Thankfully, you have supported censorship many time in the past, so I’ll have no problem trashing your comment next time if quality doesn’t improve.

      > Wow. Another remarkably dishonest article from the authors of Bitcoin Unlimited. (http://archive.is/5cim0)

      See right out of the bat, ad hominem.

      > Making your transactions non-malleable is a thing you always opt-into because some forms of mallability are an intentional and useful feature.

      Good, so that’s pretty much what i wrote in the article. However, while this is true, many SegWit supporter keeps repeating that SegWit is a malleability fix. You may want to correct them in the future.

      > Again, a complete untruth.

      Interestingly enough, you showed nothing to be untrue so far, yet you claims to have done so…

      > Segwit makes transaction hashing strictly linear in the size of the transaction.

      Only inputs spending SegWit UTXO scale linearly. It is still possible to produce an attack block once SegWit is activated.

      I could continue, but that’d be a waste of my time.

        • Great Luke, I hope this encourages newcomers to /r/Bitcoin to check out the posting histories of its most prolific and vitriolic posters. Much would be learned.

          Posting histories are public, like the moderation log at /r/btc , but UNLIKE the moderation log at /r/Bitcoin. Makes you wonder why the moderators there shy away from transparency.

          What Chomsky described as ‘Manufacturing Consent’ is going on in /r/Bitcoin and should be termed ‘Manufacturing Consensus’.

      • > I could continue, but that’d be a waste of my time.

        Not much, considering you didn’t even bother trying to refute pretty much any of my corrections– does that really take any time?

        > while this is true, many SegWit supporter keeps repeating that SegWit is a malleability fix.

        Are you trying to gaslight me? It is a malleability fix. The fact that users can choose to not make malleable transactions with it doesn’t make it any less of one.

        > Only inputs spending SegWit UTXO scale linearly. It is still possible to produce an attack block once SegWit is activated.

        It is no more possible today, and much _less_ possible than under incompatible protocol rules like BU that just jack the blocksize without fixing the problem. But again: why are you even raising this when BU strongly assumes miners are honest and can’t even be counted on to verify signatures at all in the presence of dishonest miners? … But thanks for confirming that your original claim “fails to solve anything related to quadratic hashing” was untrue with your correction that segwit inputs have linear hashing.

    • > There is no fungiblity interaction here– any coin can be sent to a segwit wallet and any coins in a segwit wallet can be sent to any other wallet, so that claim is simply untrue.

      Given that you proclaim huge problems with a simple HF upgrade of the network, there might indeed be a fungibility problem: SegWit coins can not be send to non-SegWit aware Bitcoin participants!
      You can’t have it both ways: Argue that Bitcoin cannot be hardforked because it is too difficult to upgrade the whole network and would leave people out and then, for the sake of fungibility, assume that everyone is aware of SegWit. Doesn’t compute, Greg!

      > Again, a complete untruth.

      It is telling that you like talking about ‘untruth’ so much.

      > Because segwit is backward compatible it doesn’t change older transactions (and couldn’t, without risking confiscating funds) but that is okay because segwit doesn’t increase the capacity for older transactions.

      SegWit does NOT solve quadratic hashing in the sense of getting *rid* of it. The *partial* fix of quadratic hashing would play squarely into your hands: You can continue to block further blocksize increases by telling us that they’d be unsafe, ‘because quadratic hashing issues’.

      Where are your *long-term* plans for further on-chain increases – which (trying to follow your usual lines of argument) will likely include phasing out the current transaction format?

      (But then, I think this is all a little too late anyways….)

      > Dishonest miners being able to make malicious blocks that bloat the system isn’t a new attack, but segwit makes the attack better by reducing the much more serious UTXO (https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e#.qofkg369f bloat attack vector).

      You are arguing against *facts here*. Miners *could have* bloated the UTXO for 8 years now. The attack is open for everyone to do – YET IT DOES NOT HAPPEN.

      Given that they do not do that proves that this is simply an attack not to worry about too much.

      You apparently want to micromanage Bitcoin everywhere. Bitcoin is not yours however, and the various ways you are trying to conceal this generally doesn’t help the level of argument with you.

      Furthermore: One man’s UTXO bloat is another man’s UTXO growth. As LN will not help with the size of the UTXO set, restricting UTXO growth is corresponding to restricting Bitcoin’s growth. Insanity!

      I admit that the I/O bandwidth might not be fully there, but in terms of storage, 60TB SSDs have been announced by AFAIR Seagate. That’s *already* enough storage to run a full node for the whole planet, with dozens of UTXOs per person!

      > I think this point is especially dishonest coming from a BU developer, given that their whole security model is based on a strong assumption that the aggregate behavior of miners is honest.

      That’s a foundational assumption of Bitcoin. We apparently simply can’t help you with your unwillingness to grasp the larger incentives underlying the Bitcoin system.

      > It’s like a guy who sells houses without doorlocks on the basis that people are honest complaining that someone was lowering their security replacing their deadbolt with a combination fingerprint scanner + key lock where the key was somewhat easier to copy.

      LOL. Greg, your problem is exactly that you want to force biometric fingerprint scanners on every damn door lock that is in your sight!

      Even if that is in rural Iceland, where people trust each other, know each other, and any bad guy will have a very hard time getting away from the crime scene. You are totally oblivious to the *cost* of biometric fingerprint scanners! Security is a trade-off, and always has been a trade-off.
      Ironically, your actions and intents are endangering the core security of Bitcoin, and you can’t or won’t even see it!

      This by the way also explains well the general attitude regarding 0-conf of your followers (they do not like it). Or the fear and angst around the selfish mining attack. I could go on and on here.

      0-conf – on one hand and with your limited mindset – COMPLETELY insecure, yes. YET, it worked well for many uses and small amount of money transferred. Satoshi’s vending machine scenario. It worked until you started fucking the system up with the MBSL below market demand.

      > The description given there actually argues the opposite. The funds in channels are required based on the number of channels. Lightning designs today are setup to only build channels as a product of payments you’re already making. Using lightning in a “hub like” way requires extra transactions that you never would have made normally. The big advance of lightning over the prior payment channels proposals is specifically that it doesn’t need hubs.

      Besides the fact that no workable routing scheme, incentive analysis or anything else has been provided for your blatant, dishonest assertion of ‘LN won’t be hubs and spokes’, pretty much *all* economic factors that have been looked at so far will indeed cause any network of payment channels to converge to a hubs-and-spokes model.

      You are selling the vaporware (yes parts of LN exist. But then LN is just payment channels strung together anyways, and PCs have existed since Bitcoin’s inception) of some fancy schmancy super-duper decentralized LN network.

      But there’s pretty much nothing in terms of economic analysis, both for de-/centralization pressures in a LN system as well as miner (dis-!) incentives!

      Miners not activating SegWit might well be due to your failure to properly take miner incentives into account. If so, I am glad that miners are fully awake, but it would be urgent for you to get off your high horse and see that you and Core are the reference of where things are going anymore – if you want to keep any say and influence on what happens with Bitcoin in the mid-term.

      I have seen answers regarding ‘what willl LN look like’ answered by your ilk with “Oh I don’t know, let’s find that out!”

      It is insane to cripple a well-working and known system because of invented centralization fears and ON TOP OF that propose an UNKNOWN system to replace on-chain transactions (a scheme that worked very well in the past).

      • What a fantastic response! I couldn’t have said it better myself.. core are throwing all their focus on side chain development and not even considering the main chain itself. Their road map for on chain scaling doesn’t really exist. segwit seems to have more complexity in hindering further development in bitcoin.

    • I can’t help but wonder if Bitcoin coding (by “Satoshi Nakamoto”) is actually so inferior that it needs Segwit + Lightning Network + Schnorr in order to survive.

  2. Wow, that’s a lot of bias. Not only did this post fail to address the Majority of benefits that Segwit offers, like Linear scaling of sighash operations, efficiency gains, versioning, and many others, It assumed that one version of Satoshi’s vision for lightning was the final product and attacked that version’s limitations… When in fact there are five different development teams writing Lightning code today.

    Then there’s the fact that it’s literally impossible to scale to visa’s level of transactions on-chain (Terrabyte blocks, anyone?) so some sort of Layer-two fix is absolutely required to allow bitcoin go mainstream. There is no argument between devs on that point. Since fixing TxMal is the best way to enable them, why the hell would anyone fight this improvement, no matter how much they don’t like the current winner of Lightning’s development??? It’s REQUIRED TO SCALE.

    It also didn’t spend one second talking about the horrors of a hard fork, which is the obvious way to to honor the HK agreement and raise the blocksize. Why is it that the entire community was horrified of hard forks just 2 years ago but today the BU crowd has some sort of selective amnesia about them now, not to mention a complete lack of cognizance about Ethereum’s hard fork?

    Yes, Ethereum isn’t bitcoin, but that’s a difference to make things WORSE in bitcoin’s case, not better! Confidence is the absolute #1 attribute any and all money must have. Ethereum wasn’t money, so it was no major loss of confidence to Ethereum folks when they hard forked and a new coin appeared. To investors using bitcoin as a store of value, that will be a complete dealkiller.

    Suddenly people who are thinking of bitcoin like a digital asset or stock will see what they can’t help interpret to be a stock split. There is Zero way to communicate with them otherwise. They won’t listen to us and won’t care that it’s just a software fork; they only care about the total number of things trading calling themselves bitcoins… A hard fork in this contentious environment will, with absolute certainty, take bitcoin from 21 million coins to 42 million bitcoins overnight. That’s all they’ll see and that means it’s a shitty store of value.

    Both bitcoins will go sub $1 immediately and stay there forever. All cryptocurrencies will be at risk after bitcoin’s confidence will have been dealt such a massive blow.

      • Good luck finding an actual fault in my “lies.” I had to research every single one of those facts for myself and will be happy to demonstrate any of the math I’ve used.

        You guys may not believe that the public will react the way I say they will, but maybe, just maybe, your judgement is being influenced by all the other things like censorship that is fogging your vision on the subject?

    • .A hard fork in this contentious environment will, with absolute certainty, take bitcoin from 21 million coins to 42 million bitcoins overnight, doubling the supply and making it far easier for new users to participate. Expect the aggregate value of both chains to exceed 3 or 4 times the total current market value.

      Both bitcoins will likely stay right around the current value, as long-term investors will finally start to see the benefits of forking your economic system if you don’t agree with tyranny of the majority.

      There, fixed it for ya.

      • That do not make any economic sense. You don’t double value by doubling the number of coins. If that was the case, Zimbabwe would be the richest country on earth.

      • Yeah, if theres one thing I agree with Luke Parker on, its that a contentious hardfork for Bitcoin is likely damaging to all cryptocurrencies.

  3. Dear Deadalnix,
    I hope you are reading this and that you are directly involved in Bitcoin development, because just recently I watched a Youtube video by Clif High at http://www.youtube.com/watch?v=HapWHBCFd3c where he gave a suggestion to achieve infinite scalability of Bitcoin without segwit, without increasing the block size, and without any soft/hard fork. It basically involves using just 80 free bytes in the block structure to do lateral processing that will result in infinite scalability.

    I hope you can spend some time (less than 6 minutes) to check out the video and tell me what’s your opinion. Hope that will put Bitcoin scalability issue to permanent rest.

    If Bitcoin Core does not bother with such improvement, then maybe Bitcoin Unlimited can take the lead.

    • This doesn’t provide infinite scalability. He overlooks many details. This would also be either a hard or soft fork, depending on the implementation details.

  4. Great article, everyone should read this. Not surprised to see the lunatic censor Greg Maxwell chiming in with lies and disinformation as one of the first comments. Segwit is nothing more than an attack on Bitcoin, designed to kill bitcoin, paid for by big banking investment firms who don’t want to have to compete with a truly p2p payment layer.

    BOYCOTT SEGWIT. SegwitCoin is BankCoin, not Bitcoin.

    • Hi,

      Sadly I know no chinese, so I’m not sure how I can help. If you send me your email address, I’ll loop you in the relevant discussions.

  5. Bonjour, et vive le tour !

    I enjoyed your talk on the economics of the low blocksize limit.

    I notice BIP152 talks about sending only the txids, when a new block is mined, in place of the whole transaction bodies – this would reduce block propagation latency, and address one of the only plausible arguments I’ve heard for keeping the block size small [ argument goes like this : “large block, large propagation time, miner advantage due to getting last block before others” ]

    Do you know if this was ever _implemented_ in core or is now in bitcoinabc ?

  6. Can you explain the math that segwit would give 1.7-2x the capacity? I’ve seen this figure suggested a number of times but I’m not sure how to arrive at it.

    My understanding is:
    1) The “weight” calc changes from:
    weight = transaction size
    to:
    weight = non_sig_siz * 4 + sig_size
    where total max weight per block goes from 1024^2 to 4*1024^2.
    2) That typical transactions are around 500b, and that signatures are 65b of that (https://tradeblock.com/bitcoin/historical/1h-f-tsize_per_avg-01101)
    3) ((500.0 – 65.0)*4+65)/4.0=451.25; and 1-(451.25/500)=9.7% suggesting we’d only get about 10% not 70% more transactions with segwit?

    Is there a mistake in my math or my understanding of segwit weights or typical tx sizes or?

    • Yes. a 500b transaction will likely have 2 inputs, so 2 witness fields, not just one. In addition, witness contains the signature plus the public key. Finally, the signature is bigger than you seems to think it is is, typically around 70b .

  7. >However, in the case where the chain is running at capacity, it may be very expensive, or even not possible at all for you to publish the proof within the required timeframe. In the world of LN, full blocks equals stealing.

    Very expensive? Pay market price +1 satoshi, and you’re in. Miners have incentive to include your tx if you offer competitive fee, am I right? Full blocks != stealing.

    1. Timelock can be few dozen of blocks, and one of them for sure will include your proof tx.

    2. Even if timelock is like 2 blocks, there’s no incentive for counterparty to even TRY to cheat because in that case they risk and likely will lose everything.

    Why would you offer this argument? That’s really bad one.

    2nd argument I agree with. Centralization of hubs is inevitable. Which is not a bad thing. Because hub is riskying their own money and it will be true weapon race who manages to create more secure hub. No users risk their own coins. Closing “stale” channels to increase active ones and other tricks can be used instead of spending 1 trillion IMO.

Leave a Reply

Your email address will not be published. Required fields are marked *