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.
Hard coded UTXO checkpoints are the way to go. They're safe. They're necessary.
Update 3: Pieter convinced me in the comments of his Stack Exchange answer that these checkpoints don't give any material improvement over assumevalid and assumeutxo. He made me realize why my Case IV below would not actually cause a huge disruption for assumevalid users. So I rescind my call for UTXO checkpoints. However, I maintain that UTXO checkpoints done properly (with checkpoints sufficiently in the past) are not a security model change and would not meaningfully alter consensus. It sounded like Pieter agreed with me on that point as well. I think UTXO checkpoints might still be a useful tool I will call for Assume UTXO tho. It plus assumevalid adds pretty much much all the same benefits as my proposal. OP: Luke Jr has been proposing lowering the maximum block size to 300mb in order to limit how long it takes a new node to sync up. He makes the good point that if processor power is growing at only 17%/year, that's how much we can grow the number of transactions a new node needs to verify on initial sync. But limiting the blocksize is not the only way to do it. As I'm sure you can foresee from the title, I believe the best way to do it is a hardcoded checkpoint built into the software (eg bitcoin core). This is safe, this is secure, and it is a scalability improvement that has no downsides. So what is a hardcoded checkpoint? This would consist of a couple pieces of data being hardcoded into the source code of any bitcoin full-node software. The data would be a blockheight, block hash, and UTXO hash. With those three pieces of information, a new client can download the block at that height and the UTXO set built up to that height, and then it can verify that the block and UTXO set are correct because they both have the correct hashes. This way, a new node can start syncing from that height rather than from the first block ever mined. What does this improve?
Less storage - nodes don't need to store the entire historical chain through the eons. Just very recent blocks.
Initial sync time is massively reduced
Initial sync time would scale linearly with the transaction rate (whereas now it scales linear with number of total transactions).
While not strictly necessary, its likely that the UTXO data would come from the same source as the software, since otherwise full nodes would have to store UTXO sets at multiple block heights just in case someone asks for it as part of their checkpoint. Also, full-nodes should store block information going back historically significantly further than their checkpoint, so they have data to pass to clients that have an earlier checkpoint. So perhaps if a client is configured for a checkpoint 6 months ago, it should probably still store block data from up to 2 years ago (tho it wouldn't need to verify all that data - or rather, verifying it would be far simpler because the header chain connecting to their checkpoint block would all that needs to be validated). To be perfectly clear, I'm absolutely not suggesting a live checkpoint beacon that updates the software on-the-fly from a remote source. That is completely unsafe and insecure, because it forces you to trust that one source. At any time, whoever controls the live source could disrupt millions of people by broadcasting an invalid block or a block on a malicious chain. So I'm NOT suggesting having a central source, or even any distributed set of sources, that automatically send checkpoint information to clients that connect to it. That would 100% be unsafe. What I'm suggesting is a checkpoint hardcoded into the software, which can be safely audited. So is a hardcoded checkpoint safe and secure? Yes it is. Bitcoin software already needs to be audited. That's why you should never use bitcoin software that isn't open source. So by including the three pieces of data described above, all you're doing is adding a couple more things that need to be audited. If you're downloading a bitcoin software binary without auditing it yourself, then you already take on the risk of trusting the distributor of that binary, and adding hardcoded checkpoints does not increase that risk at all. However, most people can't even audit the bitcoin software if they wanted to. Most people aren't programmers and can't feasibly understand the code. Not so for the checkpoints. The checkpoints could easily be audited by anyone who runs a full node, or anyone who can check block hashes and UTXO hashes from multiple sources they trust. Auditing the hardcoded checkpoint would be so easy we could sell T shirts that say "I helped audit Bitcoin source code!" The security profile of a piece of bitcoin node software with hardcoded checkpoints or without hardcoded checkpoints is identical. Not similar. Not almost. Actually identical. There is no downside. Imagine this twice-a-year software release process: Month 0: After the last release, development on the next release start (or rather, continues). Month 3: The next candidate version of the software is finalized, including a checkpoint from some non-contentious distance ago, say 1 month ago. Month 6: After 3 months of auditing and bug fixing, the software is released. At this point, the checkpoint would be 4 months old. In this process, downloading the latest version of bitcoin software would mean the maximum months of blocks you have to sync is 10 months (if you download and run the software the day before the next release happens). This process is safe, its secure, its auditable, and it saves tons of processing time and harddrive space. This also means that it would allow bitcoin full nodes to be run by lower-power computers, and would allow more people to run full nodes. I think everyone can agree that outcome would be a good one. So why do we need this change? Because 300kb blocks is the alternative. That's not enough space, even with the lightning network. I'm redacting the previous because I don't have the data to support it and I don't think its necessary to argue that we need this change. So why do we need this change? This change represents a substantial scalability improvement from O(n) to O(Δn). It removes a major bottleneck to increasing on-chain transaction throughput, reducing fees, increasing user security as well as network-wide security (through more full nodes), or a combination of those. What does everyone think? Update: I think its useful to think of 4 different types of users relevant in the hypothetical scenario where Bitcoin adopts this kind of proposal:
Upfront Auditors - Early warnings
After-the-fact Auditors - Late warnings
Non-full-auditors - Late warnings
Non full nodes - No warnings
Upfront auditors look at the source code of the software they use, the keep up to date with changes, and they make sure that what they're running looks good to them. They're almost definitely building directly from source code - no binaries for them. They'll alert people to a problem potentially before buggy or malicious software is even released. In this scenario, their security is obviously unchanged because they're not taking advantage of the check-pointing feature. We want to encourage as many people as possible to do this and to make it as easy as possible to do. After-the-fact Auditors want to start a new node and start using Bitcoin immediately. They want to audit, but are ok with a period of time where they're trusting the code to be connecting the chain they want. They take on a slight amount of personal risk here, but once they back-validate the chain, they can sound the alert if there is a validation problem. Non-full-auditors are simply content to trust that the software is good. They'll run the node without looking at most or any of the code. They take on more risk than After-the-fact Auditors, but their risk is not actually much worse than After-the-fact Auditors. Why? Because as soon as you're sure you're on the right chain (ie you do a few monetary transactions with people who accept your bitcoin), you're golden for as long as you use that node and the part of the chain it validated. The can also still help the network to pretty much the same degree as After-the-fact Auditors, because if there are a problem with their transactions, they can sound the alarm about a problem with that software. Non full nodes obviously have less security and they don't help the network. So why did I bother to talk about these different types of users? Well, we obviously want as many Upfront auditors as possible. However, doing that out of the starting gate is time consuming. It takes time to audit the code and time to sync the blockchain. Its costly. For this reason, for better or worse, most people simply won't do it. Without checkpoints, we don't have type 2 or type 3 users. The only alternative to being an Upfront Auditor is to be an SPV node that doesn't help the network and is less secure. With checkpoints, we could potentially change many of those people who would just use SPV to doing something much more helpful for the network. One of the huge benefits of After-the-fact Auditors and Non-full-auditors is that once they're on the network, they can act like Upfront Auditors in the next release. Maybe they're not auditing the source code, but they can sure audit the checkpoint very easily. That means they can also sound the alarm before malicious or broken software is released, just like Upfront Auditors. Why? Because they now have a chain they believe to be the true one (with an incredibly high degree of confidence). What this means is that Upfront Auditors, After-the-fact Auditors, and Non-full-auditors help the network to a very similar degree. If software that doesn't sync to the right chain, they will find out about it and alert others. Type 2 and 3 take on personal risk, but they don't put the network at greater risk, like SPV nodes do. If we can convert most Non-full nodes into Type 2 or Type 3 users, that would be massive gain for the security of Bitcoin. Luke Jr said it himself, making nodes that support the network as easy as possible to run is critical. This is one good way to do that. Update 2: Comparison to -assumevalid and why using checkpoints upgrades scalability The -assumevalid option allows nodes to skip validation of blocks before the hardcoded golden block hash. This is similar to my proposal, but has a critical difference. A node with -assumevalid on (which I've heard is the default now) will still validate the whole chain in the case that a longer chain is floating around. Because of this, -assumevalid can be an optimization that works as long as there's no other longer chain also claiming to be bitcoin floating around the network. The important points brought up by the people that wrote and discussed adding this feature was that: A. Its not a change in security model, and B. Its not a change in consensus rules. This meant that it was a pure implementation detail that would never and could never change what chain your node follows. The checkpoints I'm describing are different. On point A, some have said that checkpoints are a security model change, and I've addressed that above. I'd like to add that there is no way for bitcoin to be 100% trustless. That is impossible. Bitcoin at the deepest level is a specified protocol many people have agreed to use together. In order to join that group even on the most fundamental level, you need to find the spec people are agreeing to use. You have to trust that the person or people that gave you a copy of that spec gave you the right one. If different people claim that different specs are "bitcoin", you have to choose which people to trust. The same is true of checkpoints. New entrants want to join the network that the people they care about interacting with believe is Bitcoin, and those are the people they will trust to get the spec, or the source code, or the hash of the UTXO set. This is why I say the security profile of Bitcoin with checkpoints is identical to Bitcoin without checkpoints. The amount of trust you have to put in your social network is not materially different. While its not a security model change, as I've supported above, using checkpoints is consensus rules change. Every new checkpoint would change the consensus rules. However, I would argue this isn't a problem as long as those checkpoints are at a non-contentious number of blocks ago. While it would change consensus rules, it should not change consensus at all. There are 4 scenarios to consider: I. There's no contention. II. There's a long-range reorg from before the checkpoint. III. There exists a contentious public chain that branched before the checkpoint would usually be taken. IV. There exists an invalid chain that's longer than the valid chain. In case I, none of it matters, and checkpoints have pretty much exactly the same result as -assumevalid. In case II, Bitcoin has much bigger problems. Its simply unacceptable for Bitcoin to allow for long-range reorgs, so this case must be prevented entirely. The downsides of a long-range reorg for bitcoin without checkpoints is MUCH MUCH larger than the additional downsides with checkpoints. In case III, the obvious solution is to checkpoint from an earlier non-contentious blockheight, so nodes validate both chains. Case IV is where things really differ between checkpoints and -assumevalid. In this case, nodes using a checkpoint will only validate blocks after the checkpoint. However, nodes using -assumevalid will be forced to validate both chains back to their branch-point. I don't believe there are other relevant cases, but as long as checkpoints are chosen from non-contentious heights and have time to be audited, there is no possibility that honestly-run bitcoin software would in any way affect the consensus for what chain is the right chain. This brings me back to why checkpoints upgrades scalability, and -assumevalid does not. Case IV is the case that prevents -assumevalid from being a scalability improvement. You want new nodes to be able to sync to the network relatively quickly, so say the 90th percentile of machines should be able to do it in less than a week (or maybe we want to ensure sync happens within a day - that's up for debate). With checkpoints, invalid chains branched before the checkpoint will not disrupt new entrants to the network. With -assumevalid, those invalid change will disrupt new entrants. Since an invalid chain can have branched arbitrarily far in the past, this disruption could be arbitrarily large. One way to deal with this is to ensure that most machines can handle validating not only the whole valid chain, but the whole invalid chain as well. The other way to deal with this is checkpoints. So back to scalability, with checkpoints all we need to ensure is that the lowest power machines we want to support can sync in a timely manner back to the checkpoint.
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.
Hardcoded UTXO checkpoints are an enormous scalability improvement.
Update 3: Pieter Wuille convinced me in the comments of his Stack Exchange answer that these checkpoints don't give any material improvement over assumevalid and assumeutxo. He made me realize why my Case IV (see the other post) would not actually cause a huge disruption for assumevalid users. So I rescind my call for UTXO checkpoints. However, I maintain that UTXO checkpoints done properly (with checkpoints sufficiently in the past) are not a security model change and would not meaningfully alter consensus. It sounded like Pieter agreed with me on that point as well. I think UTXO checkpoints might still be a useful tool I will call for Assume UTXO tho. It plus assumevalid adds pretty much much all the same benefits as my proposal. OP: Hardcoded checkpoints are a piece of code in a Bitcoin node software source code that define a blockheight, a block hash, and a UTXO hash as valid. A new Bitcoin node would only need to validate blocks back to the golden blockheight, greatly reducing initial sync time. This would not change Bitcoin's security model. And while it does add a consensus rule, it would not actually ever have any significant likelihood of changing what the consensus is for which chain is the true chain as long as the checkpoints are taken from a non-contentious blockheight (say 1 month ago, since a reorg from a block 1 month ago is basically impossible). What checkpoints would do is allow much lower-power machines to be used as fully-validating nodes on the network, which would substantially increase Bitcoin's security. Luke Jr has been proposing lowering the blocksize to 300mb, and he has a point. Processor power is the bottleneck for spinning up new full nodes, and processor power isn't growing like it used to. Even tho he has a point, I believe that ship has sailed and it's unlikely that we'll roll back the max block size. But what that means is that even if we stay with the current max blocksize of around 2MB, initial sync time will go up and up for decades before coming back down to reasonable levels in over 40 years. That's a scary thought. Checkpoints is an alternative to that scenario that I believe has no downside, and only upsides. See the discussion happening on BitcoinDiscussion.
Newbs might not know this, but bitcoin recently came out of an intense internal drama. Between July 2015 and August 2017 bitcoin was attacked by external forces who were hoping to destroy the very properties that made bitcoin valuable in the first place. This culminated in the creation of segwit and the UASF (user activated soft fork) movement. The UASF was successful, segwit was added to bitcoin and with that the anti-decentralization side left bitcoin altogether and created their own altcoin called bcash. Bitcoin's price was $2500, soon after segwit was activated the price doubled to $5000 and continued rising until a top of $20000 before correcting to where we are today. During this drama, I took time away from writing open source code to help educate and argue on reddit, twitter and other social media. I came up with a reading list for quickly copypasting things. It may be interesting today for newbs or anyone who wants a history lesson on what exactly happened during those two years when bitcoin's very existence as a decentralized low-trust currency was questioned. Now the fight has essentially been won, I try not to comment on reddit that much anymore. There's nothing left to do except wait for Lightning and similar tech to become mature (or better yet, help code it and test it) In this thread you can learn about block sizes, latency, decentralization, segwit, ASICBOOST, lightning network and all the other issues that were debated endlessly for over two years. So when someone tries to get you to invest in bcash, remind them of the time they supported Bitcoin Unlimited. For more threads like this see UASF
I'm an early Bitcoin adopter. As of today, I own no Bitcoin. RaiBlocks is my biggest holding. Here are my thoughts regarding the current situation.
I might get some shit for this, even from this community. I was an early adopter in Bitcoin since 2013 when the BTC price was in double digits. I didn't buy an insane amount, but I also didn't sell until mid to late 2017. I held through the Mt. Gox scandal, Silk Road shutdown, all of the China bannings... The first time I sold any was when Jihan and his crew announced that they would hard fork. The community had already become toxic, and everything you saw on Reddit was related to the "war" and how other coins sucked. This was in contrast to the good ol' days when you could go online and read about the technology and its progress. Despite all of the drama, I was still a Bitcoin fanatic. I didn't like Ethereum at the time because all of the Ethereum fanboys were talking shit about Bitcoin and how "the flippening" was coming, and I was on the "Bitcoin side." Slowly, I had started to lose faith in Bitcoin due to this ever-worsening dipolar situation where the Bitcoin fans had divided into Core supporters vs Bcash supporters. The Core devs would absolutely refuse to allow 2mb blocks (and mentally insane Luke Jr even wants to reduce BTC blocksize), and the Bitcoin Cash fans wanted endless blocksize with no Segwit or other improvements. Kind of like Democrat versus Republican where you need to be one or the other, or else you don't fit in. There is an old Arab proverb: “I against my brother; I and my brother against my cousin; I and my brother and my cousin against the world.” Unfortunately we are still not at the point where we can act amicably towards one another - even in cases where two coins are not direct competitors... And I realize now how I got sucked into the Bitcoin cult and the r-bitcoin vs r-btc war. I realize that I had slowly become blind. In late 2017, I was still moving BTC around in contrast to some people who put it into cold storage and forget about it. I was quickly becoming tired of waiting to see if my $15 fee transaction would get me into the next block or three. I was tired of waiting to see when my transaction would get its first confirmation. I would wait between one hour and days to see when my transaction got a certain amount of confirmations. In the early days of Bitcoin, the most popular meme and one of the few memes posted was comparing the transaction costs of Western Union and MoneyGram to Bitcoin. In early December I sold some BTC for RaiBlocks. It was a new technology that I didn't know much about (relative to Bitcoin, which I know a lot about), and it wasn't popular at all. When I read more about Raiblocks, I sold all of my "faster" altcoins into it (i.e. Litecoin and Vertcoin). And even more of the "king" Bitcoin. I grow tired of people trying to make a quick buck while fomo'ing into shitcoins and not caring about technology or purpose. Bitcoin no longer deserves to be in the #1 spot. As of today, I own no Bitcoin. I sold every last bit of it. I put it into RaiBlocks and Monero, and Ethereum. I put my money in the coins that deserve it. The coins that the world needs. And the three biggest needs in my opinion are that of a fast, digital, decentalized currency with no fees; a complete privacy coin that may be slower and higher in fee; and a platform for applications. Bitcoin is the next Myspace. It no longer solves a problem or fulfills a need. Nano. Monero. Ethereum. Nano/RaiBlocks is doing remarkably well despite these exchange problems. The developers are doing a remarkable job. Hell, even BitGrail may be doing a really good job with respect to the amount of resources they have. Remember the saying "be greedy when others are fearful"? Stop being so god damn impatient! If Nano were to fail for some weird reason, then so be it. I'll see you guys later, one way or another. Either on the sea floor or the moon.
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.
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.
There is no voting in Bitcoin. You can set up a million BIP148 nodes and it won't make any difference. For that matter, any individual person doesn't have much economic force, so I'm not sure that it'd make much difference even if you got 50% or 75% or 90% of /Bitcoin users to personally hard-enforce BIP148. You need significant economic actors: Bitcoin-accepting businesses, exchanges, etc. Maybe it's possible to succeed in a UASF without much business support, but then you need massive end-user support, which requires default-on hard enforcement in common software like Core. You're never going to succeed with grassroots political tactics but ~no time, ~no business support, and ~no default-on support in common software.
So it's pretty clear that the overlord of /bitcoin thinks that the majority of bitcoin users have no power towards it's development and direction. This started as him banning big blockers because he thinks he is smarter than the majority. And recently he's saying that the "majority" he has created in his echo-chamber have no power, but the businesses and exchanges do. Well, the businesses, exchanges and miners have decided, just like he said. Except it's on segwit2x. But what's going on in /bitcoin now? (I don't believe these posts claiming they have the majority of user's support. It's just interesting how their thought process contradicts their leader who BANNED the majority and doesn't believe in the majority.) https://np.reddit.com/Bitcoin/comments/74mydg/the_smart_money_is_on_btc/
Today, the large majority of the bitcoin user base supports the core roadmap.
-There's also Luke-jr sybil resistant poll which indicate that the majority of users do not want a hard-fork now.
There are tons of posts like this all over /bitcoin. So the "majority" is right? Then why wasn't the real majority right in the first thread I posted before theymos banned everyone? I guess the majority is only right when theymos has manufactured it. So theymos = majority. Always. The /bitcoin "majority"TM and a few troll companies are literally all they have left after shifting the goal posts after every loss. Let's finish this in November.
Exchange Reviews; Wallet Reviews ; Menu × ACA News ... 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, ... Bitcoin Improvement Proposals. Contribute to luke-jr/bips development by creating an account on GitHub. Luke Dash Jr. is a Bitcoin Core (BTC) developer and he seems to constantly be in the middle of some kind of controversy. One of his most recent comments to get some attention is regarding the block size on the BTC chain, which he suggested reducing down to 300kb. #5 Luke-jr. One of the more colorful figures in the bitcoin ecosystem goes by the nickname Luke-jr. He is not afraid to share some controversial thoughts on the bitcoin ecosystem and what the ... Luke-Jr 2014-10-06 04:02:05 UTC All entries on the blacklist are known DDoS attacks against the Bitcoin network, not political. The vanilla code already attempts to ignore (and thereby mitigate) these kind of attacks. The blacklist feature is just an admittedly ugly hack to improve the reliability of the detection based on known factors - it is unsuitable for the reference code because it ...
ByBit Exchange Tutorial: How to Long or Short Bitcoin ...
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. How to Exchange Bitcoin to Ether using blockchain - Duration: 3:25. Mulla Eshcol 18,141 views. 3:25. How to buy ripple (XRP) - Duration: 5:57. ... 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. (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:... Small block proponent and Core Dev member Luke Jr is asked Why he is interested in Bitcoin. (He isn't sure) Bitcoin Cash proponent and CEO of Bitcoin.com Roger Ver gives his answer to the same ...