What the upcoming years might hold in store for bitcoin (a technical outlook by John Newbery)
John Newbery is a developer contributing to Bitcoin Core and to various educational resources like Bitcoin Optech. Original source is here:https://twitter.com/jfnewbery/status/1208559196465184768. Keep in mind that the text below is copied from Twitter, so the formatting/phrasing might seem a little strange. -------------------------------------------------------- The end of the decade is a good time to look back and marvel at the giant strides that Bitcoin has made since Satoshi gave us the whitepaper in 2008. It's also a natural point to look forward to what the upcoming years might hold in store. This is where I think Bitcoin is headed over the next few years. Tell me why I'm wrong and what I've missed! The lightning protocol teams working on c-lightning (@Blockstream), eclair (@acinq_co), LND (@lightning) and rust lightning will continue to iterate rapidly on the lightning protocol. All implementations now support basic multi-path payments (https://bitcoinops.org/en/topics/multipath-payments/). We'll get better support of that as well as dual-funding, splice-in and splice-out (https://bitcoinops.org/en/topics/splicing/). Taken together, those technologies will make channel and liquidity management much easier. They'll be automated, fade into the background and user experience will improve drastically. Lightning infrastructure will improve. @bitfinex recently added lightning deposits and withdrawals. All other exchanges, merchant service providers, custodians and wallets will follow suit or become obsolete. We'll see more lightning wallets: a mix of non-custodial; self-custodied with outsourced routing; and fully-self-managed wallets. This is a brand new space and there'll be lots of experimentation. Different teams will find different niches to fill. Already, wallets like @MuunWallet, @Breez_Tech, @PhoenixWallet, @ln_zapand @bluewalletio are experimenting with different models. Tooling for lightning developers will improve. When we ran the lightning apps residency just over a year ago, the attendees spent a lot of time setting up their lightning dev environments. Now, with Polar (https://github.com/jamaljspolar) by @jamaljsr, lightning app developers can set up a test environment with a few clicks. More and better tools will continue to appear. With better tooling, we'll see faster innovation on the application layer. Teams at @zebedeeio, @SatoshisGames, and others we haven't heard of yet will delight us with new and unexpected lightning experiences. The schnortaproot softfork (https://bitcoinops.org/en/topics/taproot/) will be activated in 2020 or 2021. That'll provide a huge improvement in fungibility, privacy, scalability and functionality. For an overview of the benefits, watch the Optech exec briefing here: https://bitcoinops.org/en/2019-exec-briefing/#the-next-softfork That'll allow lightning to upgrade from HTLCs to Payment Points. That's a big improvement for privacy and payment decorrelation, and allows 'Stuckless payments' with proofs-of-payment -- another huge boost in LN usablity. See the @suredbits series of blog posts here https://suredbits.com/payment-points-part-1/ for more details on Payment Points. Even better, lightning channel opens and closes will look identical to payments to single pubkeys. The same is true for payments to k-of-n pubkey thresholds. That's good for fungibility, privacy and scalability. In fact, with schnortaproot, there's almost no downside to encumbering UTXOs with advanced scripts instead of single pubkey outputs. Cold storage UTXOs will be k-of-n multisig keytrees, and all hot wallet UTXOs will be stored in channels (with splicing-out used to make on-chain payments). When transactions hit the chain, they'll look like any other single pubkey/signature payment. Payments into wallets will pay directly into channel open outputs (thanks to @esneider for pointing this out to me). There'll be no concept of an on-chain balance and an in-channel balance. Just a single, unified balance that can be used for lightning or on-chain payments. Wallet teams will collaborate on a PayJoin payment protocol (https://bitcoinops.org/en/topics/payjoin/). A large number of on-chain transactions will be 2-input-2-ouput transactions, vastly improving fungibility and privacy, and foiling chain analysis. The inputs to those PayJoin transactions may be channel splice-outs, and the outputs may be channel opens, but there'll be no way to tell from observing the chain. Eventually we'll have cross-input signature aggregation (https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/#signature-aggregation), which means those PayJoin transactions will only have a single signature, and will be *cheaper* than regular change-producing transactions. Larger coinjoins will be cheaper still. An advanced PayJoin payment protocol could even batch multiple payments to the same merchant/exchange and use only a single signature. We'll get SIGHASH_NOINPUT or SIGHASH_ANYPREVOUT (https://bitcoinops.org/en/topics/sighash_noinput/), making eltoo (https://bitcoinops.org/en/topics/eltoo/) possible, and blurring the lines between layer 1 and layer 2 (https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Septembe002136.html). That'll make lightning even more usable and allow more advanced layer 2 contracts like channel factories (https://bitcoinops.org/en/topics/channel-factories/). All these advanced features will require greater wallet interoperability. That's where miniscript (https://bitcoinops.org/en/topics/miniscript/) comes in. With miniscript, wallets will eventually be able to enter contracts with each other that don't require pre-templated scripts (as lightning currently does). This wallet interoperability will allow faster innovation in layer 2 contracts. OP_CTV (https://bitcoinops.org/en/newsletters/2019/12/04/#op-checktemplateverify-ctv) or some other covenant-enabling opcode will be activated, allowing richer layer 2 constructions like joinpools (https://freenode.irclog.whitequark.org/bitcoin-wizards/2019-05-21#1558427254-1558427441). Taken together with taproot and SIGHASH_NOINPUT, we'll get extremely rich and private off-chain contracts will be made possible. Some of these things will happen in 2020, and some will take a bit longer, but they're all heading in the same direction: using the chain for what the chain's good for (h/t Andrew Poelstra). That's to say: the block chain allows nodes to arrive at an agreed ledger state, while contracting and functionality move up onto layer two. Doing so is cheaper, more secure, more private and allows for more rapid innovation. None of this is inevitable, and none can happen without the industry of many hands and the creativity of many minds. There are years of work ahead for developers, researchers, businesses and users. If you run a Bitcoin business, you can help by supporting, sponsoring or hiring open source developers. If you're a Bitcoin user, you can help by *demanding* that any service you use supports the open source ecosystem. If you're a developer, you can help by reviewing and testing PRs and releases. https://bitcoincore.reviews/ is a great place to start. 2020 is going to be a great year for Bitcoin and Lightning protocol development! /fin
“The goal of Bitcoin.com is to continue the original vision of Bitcoin and help spread peer-to-peer electronic cash to the world. Our greatest opportunity to do this is with Bitcoin Cash (BCH). Bitcoin.com aims to make trading with your fellow man an inalienable human right. We are fighting for the global adoption of permissionless, uncensorable money. While revenue is certainly one of the many goals of Bitcoin.com, and is one we want to keep front of mind, it is only one cog in the many wheels that keep Bitcoin.com driving the industry forward.” -- Roger Ver
Electron Cash coin splitting tool (for Nov 2018 hardfork) released!
Together with Mengerian and Jonald Fyookball, I've coded up and released an Electron Cash coin splitting tool for the November 15, 2018 chain splits: https://github.com/markblundeberg/coinsplitter_checkdatasig/releases/tag/3.3.1CS Along with the tool is a user guide explaining how it can be used to safely split coins . The purpose of this tool is to give users more control over their coins if it turns out that the BCH network splits into two chains (or more) on November 15th. It allows people to give their coins "replay protection", by making it possible to spend coins using a script which is valid only on a chain following the upgraded Bitcoin Cash ruleset that includes OP_CHECKDATASIGVERIFY. The tool also allows the user to later move the coins on the Bitcoin SV chain using a separate script that will be valid on both chains. This allows users and exchanges to protect themselves from replay attacks. More information about Electron Cash ecosystem can be found in an announcement made by Jonald, today: https://electroncash.org/nov2018.html ... Added offer!On fork day, I am planning to personally create some more experimental transactions that are only compatible with bitcoin SV. This (together with the tool) allows a full two-way split where neither side's transactions can be replayed on the other. If you are interested in receiving SV-only coins, please send a tiny nominal amount (the network minimum is 546 satoshis) to my address bitcoincash:qrsplterpal0qx0ncerywfq2m7rjmyle3vzcektuccbefore fork day. Then, I will try to arrange for an SV-only coin to be sent back to the first input address, as soon as possible after the fork activates. You can then mix the received SV-only coin with your other coins, and thus start making transactions on SV that definitely cannot be replayed elsewhere.Edit: As it's just as easy for me, I will also be sending some small ABC-only dust to all addresses. The ABC-only tx and SV-only tx will each be marked with an OP_RETURN message. In case it is not obvious, I am planning on keeping excess funds as donations. I'm no longer accepting further requests on this address. Update here about which txes I made.
Hi everybody, I'm holding a meetup in the DFW area for people interested in Urbit next month. If you're interested in the project or want to learn more about it, come hang out! Details are at the end of the post. I've got the blessing of u/ZorbaTHut to post this here contingent on explaining why Urbit is interesting, both in general and for this audience, so I'll give you a brief outline of the project if you're not familiar, and answer questions you may have once I'm home from work on Monday (though I encourage anybody else who'd like to to chime in until then -- I have to go to bed soon.)
What is Urbit?
Urbit is an interenet decentralization project, and a full networked computing stack from the ground up. Urbit's ultimate goal is to build a new internet on top of the old one, that is architecturally designed to avoid the need for centralized services by allowing individuals to run and program robust personal servers that are simple to manage. When Urbit conquers the world, your digital identity will be something you personally permanently own as a cryptographic key, not an line in a corporation's database; Facebook and Twitter will be protocols -- encrypted traffic and data shared directly between you and your friends & family, with no middlemen spying on you; your apps, social software and anything you program will have secure cryptocurrency payment mechanisms as a system call, payed out of a wallet on a device you fully control; and you will tangibly own and control your computer and the networked software you use on it. As I said, Urbit is a stack; at its core is Nock, a minimal, turing-complete function. Nock is built out into a deterministic operating system, Arvo, with its own functional programming language. For now, Arvo runs as a process, with a custom VM/interpreter on *nix machines. Your Arvo instance talks to other instances over a native, encrypted peer-to-peer network, though it can interface with the normal internet as well. Urbit's identity management system is called Azimuth, a public key infrastructure built on Ethereum. You own proof of your Urbit instance's identity as a token in the same way you own your Bitcoin wallet. Because the peer-to-peer network is built into Arvo, you get it 'for free' with any software you write or run on it. You run your own personal server, and run all the software you use to communicate with the world yourself. Because all of your services are running on computer you control using a single secure identity system, you can think of what it aspires to like a decentralized, cypherpunk version of WeChat -- a programmable, secure platform for everything you want to do with your computer in one place, without the downsides of other people running your software.
Why is it interesting?
Urbit is extremely ambitious and pretty strange. Why throw out the entire stack we've spent half a century building? Because it's a giant ball of mud -- millions of lines of code in the Linux kernel alone, with all the attendant security issues and complexity. You can run a personal server today if you're technically sophisticated; spin up a VPS, install all the software you need, configure everything and keep it secure. It's doable, but it sucks, and your mom can't do it. Urbit is designed from the beginning to avoid the pitfalls that led to cascading system complexity. Nock has 12 opcodes, and Arvo is somewhere in the neighborhood of 30,000 lines of code. The core pieces of Urbit are also ticking towards being 'frozen' -- reaching a state where they can no longer be changed, in order to ensure that they remain absolutely minimal. The point of all of this is to make a diamond-hard, unchanging core that a single person can actually understand in its entirety, ensure the security of the architecture, prevent insane dependency hell and leaky abstractions from overgrowing it, and allow for software you write today to run in a century. It also aims to be simple enough that a normal person can pay a commodity provider $5/mo (or something), log into their Urbit on their devices, and control it as easily as their phone. Urbit's network also has a routing hierarchy that is important to understand; while the total address space is 128-bit, the addresses are partitioned into different classes. 8-bit and 16-bit addresses act as network infrastructure, while human instances use 32-bit addresses. To use the network, you must be sponsored by the 16-bit node 'above' you -- which is to say 'be on good terms'. If you aren't on good terms, that sponsorship can be terminated, but that goes both ways -- if you don't like your sponsor, you can exit and choose another. Because 32-bit addresses are finite, they're scarce and have value, which disincentivizes spam and abuse. To be clear, the sponsor nodes only sign/deliver software updates, and perform peer discovery and NAT traversal; your connections with other people are direct and encrypted. Because there are many sponsor nodes, you can return to the network if you're kicked off unfairly. In the long term, this also allows for graceful political fragmentation of the network if necessary. The world created by Urbit is a world where individuals control their own data and digital communities live according to their mores. It's an internet that isn't funded by mass automated surveillance and ad companies that know your health problems. It's also the internet as a frontier like it once was, at least until this one is settled. Apologies if this comes off a little true-believer-y, but this project is something I'm genuinely excited about.
The world that Urbit aims to build is one not dissimilar from Scott's archipelago communism -- one of voluntaristic relations and communities, and exit in the face of conflict & coercion. It's technical infrastructure to move the internet away from the chokepoints of the major social media platforms and the concentration of political power that comes with centralized services. The seismic shifts affecting our institutions and society caused by the internet in the last decade have been commented on at length here and elsewhere, but as BTO said, you ain't seen nothin' yet. I suspect many people with a libertarian or anti-authoritarian bent would appreciate the principle of individual sovereignty over their computing and data. The project is also something I've discussed a few times with others on here, so I know there's some curiosity about it. The original developer of Urbit is also rather well known online, especially around here. Yarvin is a pretty controversial figure, but he departed the project in early 2019.
There's a lot more that I haven't mentioned, but I hope this has piqued your interest. If you're in DFW, you can find details of the first meetup here. There will be free pizza and a presentation about Urbit, help installing & using it (Mac & Linux only for now), as well as the opportunity to socialize. All are welcome! Feel free to bring a friend. If you're not in North Texas but are interested, there are also other regional meetups all over the world coming up soon.
Rick Falkvinge: The SWOT chart has changed between 2011 and 2018 for bitcoin. Things that used to be impressive, such as instant phone-to-phone cash transfers, are often now a minimum bar to even play.
Enough's enough - After doing my research on Core and Blockstream, I think it's worth dropping half(?) my portfolio into Bitcoin Cash.
Between the infighting happening with Segwit and Segwit2x, censorship over on /bitcoin and the ICO boom, Bitcoin Cash really stands out to me as the safe 3rd party. Not only that, but looking at the original whitepaper which was reposted on Halloween, it seems pretty obvious how Core is beginning to stray from Satoshi's vision, and how Bitcoin Cash is (hopefully) aiming to achieve it. I hope Bitcoin Cash continues to innovate and strive to be the number 1 form of electronic cash! Excited for the upcoming fork and what it may bring.
Idea: script opcode that puts constraints on the output addresses
I'm going to start with the reason I want this feature, and then get to describing more about the feature idea itself. Let's say I want to setup a cold-storage wallet setup that I can spend only after a relative 1 week time lock. This could theoretically work by creating two addresses:
One address has a relative timelock condition - any funds sent to this address can only be spent after 1 week with private key 1.
Another address that can be spent from using private key 2, but funds must be sent to the first address.
So in order to spend from this dual-wallet (non multisig) setup, you would sent from address 2 to address 1 using PK2, then after a week spend from address 1 using PK1. This would, for example, make the $5 wrench attack a lot harder to do (ie it would turn into a 1 week hostage attack). The problem is, I don't believe there's any way to create address 2 in bitcoin - there's no way to create an address that can only be spent to a particular other address. This is where the idea for a new opcode comes in. If there was an opcode that constrained what addresses could be sent to, this would give bitcoin a lot more power to have multi-stage transactions like this, where any stage could potentially be cancelable/reversible. Here's an example of a wallet setup I would love to be able to create:
Can be spent by Key1, Key2, or Key3.
Requires funds are sent to address 2.
3 of 3 keys can spend after 1 week
2 of 3 keys can spend after 2 months
1 of 3 keys can spend after 1 year
If I could create a wallet setup like this, I could watch Address 2 for attempts to steal funds. If an unexpected transaction happens, you could gather all 3 keys and prepare a transaction to send. As long as only up to 2 of 3 keys were compromised and you are able to react within 2 months, your funds would be safe. In addition, you could lose access to 2 of 3 keys and still be able to recover your funds with the last one (after waiting a year). This would be more secure than a normal multisig address, and also more resilient to key-loss. It would allow more secure inheritance by ensuring that heirs can retrieve the funds even if your primary passphrase-protected key has been lost (because your passphrase was lost when you died), and it would allow much more safely being able to store some keys with custodians (like banks) without almost any risk. What do people think? Is this ability worth pursuing?
Price and Libra posts are shit boring, so let's focus on a technical topic for a change. Let me start by presenting a few of the upcoming Bitcoin consensus changes. (as these are consensus changes and not P2P changes it does not include erlay or dandelion) Let's hope the community strongly supports these upcoming updates!
The sexy new signing algo.
We have a simpler proof of the security of Schnorr than the current ECDSA: a general heuristic is that a simpler proof is better since simpler proofs have less complexity for vulnerabilities to hide in. In practice most cryptographers would consider these roughly equivalent in security.
Linear signatures. This lets you do some operations on signatures which include making it possible for a n-of-n signing group to construct a single pubkey and signature, as well as providing secret communications channels (i.e. you provide the difference between two scalars privately, then create a signature using one scalar and publish it, which reveals the other scalar, letting you communicate this scalar while providing a signature that validates a transaction).
As a completely new signing scheme we can optimize signatures and public keys a little more than the existing ECDSA Bitcoin signatures, to help reduce resource usage. For instance an SECP256K1 point requires 257 bits to store, which is typically stored as one byte for the "extra" 1 bit and 32 bytes as the remaining 256 bits, but this extra bit is really the "sign" of the point (positive or negative) and we can enforce certain restrictions like "always use positive points", and a scalar which produces a negative point can be "negated" to produce a positive point, letting us cut out one entire byte from precious onchain space.
The Schnorr patent strongly discouraged development of Schnorr signatures. For this reason there are still details that hadn't been hammered out. The bip-schnorr proposal by Pieter hammers down some details, but there are still some concerns about multisignature and more complex usages below that are still being investigated.
A provably-secure way for a group of n participants to form an aggregate pubkey and signature. Creating their group pubkey does not require their coordination other than getting individual pubkeys from each participant, but creating their signature does require all participants to be online near-simultaneously.
Provably-secure. We already knew from Schnorr's work that Schnorr signatures allow multiparticipant signing, but his original proposal was actually insecure (this is part of the disadvantage caused by Schnorr patenting the signature scheme, nobody bothered to correct his multiparticipant signing procedure because why give free work for him?).
We can create a group pubkey without telling the group we made such; we only need to get their individual pubkeys. This can be useful in some protocols, e.g. escrow protocols where we elect a group of n-of-n participants as a possible escrow signer; we create this group pubkey from the published pubkeys of the escrow services, but only reveal to them that this group pubkey involves them later in case of dispute (signing requires everyone's cooperation); if the trade has no dispute at all then the escrow group never needs to learn that the group pubkey included them or that the trade was potentially an escrow trade.
Creates just a single signature and pubkey, greatly reducing the space needed onchain for n-of-n groups.
No actual change in consensus needed, other than supporting Schnorr signatures as a consensus signing scheme.
Only n-of-n; m-of-n requires verifiable secret sharing in addition to MuSig. In particular, for m-of-n we require that the participants also cooperate while generating the group pubkey (unlike the n-of-n case where we can just get published pubkeys, the m-of-n case requires that we perform some cooperative calculation to generate the private key shares for each participant).
Unlike separate-signatures-and-pubkeys multisig (i.e. what current OP_CHECKMULTISIG does), participants cannot simply send a signature it generates by itself and then go offline in no specific order. Instead, participants have to cooperatively generate a temporary signing nonce and then generate the signature. This is what forces all participants to be online at the time of generating the signature. This can be mitigated somewhat since you can pass around partial signatures, so once you have gotten the agreed-upon nonce and then created your partial signature, you can then go offline. This might not be a particularly big disadvantage but existing protocols might require an extra message turnaround in order to handle the multiple-rounds nature of MuSig.
Hiding a Bitcoin SCRIPT inside a pubkey, letting you sign with the pubkey without revealing the SCRIPT, or reveal the SCRIPT without signing with the pubkey.
You can show a SCRIPT and ignore the pubkey, or sign with the pubkey and ignore (and never reveal) the SCRIPT. This can be simulated somewhat with current Bitcoin by using a separate transaction that pays from a pubkey (or m-of-n or n-of-n multisig) to a SCRIPT, which you only publish if you want to take the SCRIPT path, but Taproot optimizes this by letting you dispense with that separate transaction. Some protocols that want to have some privacy (CoinSwap in particular) will need to have some way to hide the SCRIPT path and just use a pubkey (or m-of-n or n-of-n) in the "best case", and Taproot allows the "worst case" SCRIPT path to be somewhat more optimized if we need to take that branch.
The exact proposed mechanism in bip-taproot by Pieter allows another version number to be embedded. So not only do we have current 16 available SegWit versions (v0 already in use, v1 is intended to be taken for Taproot, v2->15 are for future expansion) we also extend SegWit v1 to have 256 "script versions" too, only one of which will be used for MAST (see below). A new "script version" can completely drop the current stack-based SCRIPT language and replace it with a completely new language, for example.
As a new SegWit version we can change the rules of the SCRIPT language to clean up some infelicities of the existing SCRIPT. For example, instead of OP_NOP operations we have OP_SUCCESS operations in the Taproot SCRIPT. When a softfork changes an OP_NOP to a different opcode, it can only either fail the SCRIPT or do nothing to the stack. When a softfork changes an OP_SUCCESS to a different opcode, it can do anything, including put new items on the stack, rearrange the stack, and so on.
It uses the pay-to-contract construction, which is used to allow a UTXO to commit to a message (in Taproot's case, the SCRIPT) without spending more space other than the pubkey it pays to. However, other schemes might want to use pay-to-contract (because of the space savings of the ability to embed a message commitment without adding more space beyond the pubkey), so care must be taken to ensure that such schemes using pay-to-contract do not conflict with Taproot itself.
Having a "SCRIPT only" UTXO (i.e. one which cannot be spent using a simple signature, but requires some more complex SCRIPT) requires that we compute a "nothing up my sleeves" (NUMS) point, i.e. a pubkey which we generate in such a way that we, or anyone, cannot possibly learn the corresponding privkey. This is already doable but requires that we actually use NUMS if we want a UTXO that can only be spent via a particular SCRIPT.
Encode each possible branch of a Bitcoin contract separately, and only require revelation of the exact branch taken, without revealing any of the other branches. One of the Taproot script versions will be used to denote a MAST construction. If the contract has only one branch then MAST does not add more overhead.
Privacy; branches not taken are not revealed, potentially hiding the possible participation of some entity with known pubkey if that entity ends up not signing for that branch.
Can be used to emulate m-of-n while using only n-of-n MuSigs (remember, n-of-n MuSig can be set up by knowing only the pubkeys of all participants, but m-of-n requires that the participants split up an n-of-n MuSig key into m shares, and each participant has to remember its own share (which can be difficult for hardware wallets to safely do)). To emulate m-of-n, you just get every subgroup of m participants, create an m-of-m MuSig pubkey for each subgroup, then make multiple OP_CHECKSIG scripts, each of which you treat as a "separate branch" in the MAST (you probably want to use a NUMS point as the Taproot pubkey that hides the MAST scripts, or select which sub-group of m is the most likely to be online later and put that as the Taproot pubkey). You need to have m participants online at signing time. This has the side effect of not revealing participants who didn't sign.
Requires O(log n) data to be revealed for n branches. This mildly leaks some information: if you see q data to prove the MAST, then the number of branches is between 2q-1 and 2q . This can be twisted around to make unbalanced MAST trees, but unbalanced MAST trees imply that some branches are more likely than others (you'd put the more likely branches in the leaves that are nearer to the root, so fewer data revealed == more likely), which again can be a mild information leak. Might not be particularly bad information leak in practice, but for example Graftroot (which is not yet proposed) achieves O(1) data revelation for n branches, leaking no data at all on the number of other branches and/or the probability of the revealed branch.
A Guide To The BCH Fork on November 15th - Be Informed!
BCH November 15th Forking Guide
Intro As you may have heard, on 15th November 2018 the Bitcoin Cash Blockchain will fork into at least two separate chains. We felt it our duty to provide information to the community on the situation that we hope will offer some clarity on this rather complex situation.
What Is A Fork? A fork occurs when at least one group of miners decide to follow a separate set of rules from the current consensus protocol. Due to the way bitcoin is designed, these miners will then operate on a separate network from the current network. This was in fact how Bitcoin Core and Bitcoin Cash was created from the original Bitcoin. Both changed the consensus rules in different ways that made them incompatible. To make the current situation slightly more complex, there are to be two sets of miners that are changing the protocol rules away from the current protocol. It is not expected that the currently operating consensus rules will be in operation by any significant set of miners after November 15th. This means that after November 15th there will be two new sets of competing protocol rules. For simplicity these will be described as the BitcoinABC ruleset and the BitcoinSV ruleset (although other implementations such as Bitcoin Unlimited, bcash, bchd, BitcoinXT and bitprim all also have the ABC consensus ruleset). This is quite a unique fork situation as one side (BitcoinSV) has indicated that they will be willing to attack their competition (BitcoinABC) using reorgs and doublespends to destabilise and reduce confidence in it.
BitcoinABC Fork Details The main new features in the BitcoinABC that make it incompatible with the current protocol are CTOR and DSV. To summarise: CTOR (Canonical Transaction Ordering) is a technology that allows blocks to be transmitted in a much more efficient way. This means that as blocks become larger as the network gains more adoption, the hardware and bandwidth requirements on nodes is decreased. This reduces centralisation pressures and allows us to scale the network with fewer adverse effects. You can read more about CTOR in this excellent ARTICLE by u/markblundeberg. DSV (CheckDataSigVerify) is a technology that allows oracles directly on the Bitcoin blockchain. This means that the transactions on the Bitcoin blockchain can be dependent on actions that happen in the real world. For example you could bet on the weather tomorrow, or if a specific candidate wins an election, all directly on the blockchain. You can read more about DSV at this excellent ARTICLE by u/mengerian.
BitcoinSV Fork Details The main new features in the BitcoinSV that make it incompatible with the current protocol are an increase in the default block size limit to 128MB, increase of the 201 opcode limit within Bitcoin’s script system to a maximum of 500 opcodes, and a new set of opcodes including; OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT. The increase in the default block size limit will in theory allow miners on the BitcoinSV ruleset to produce and propagate blocks up to 128MB in size. It may be the case that the current state of the network cannot handle, or at least sustain, 128MB blocks but this will allow miners to decide if they want to try and produce blocks over 32MB (the current protocol limit agreed upon by miners). Increasing the opcode limit will allow miners to make transactions using scripts of larger lengths. This means that more complex scripts can be developed. The new opcodes allow new operations to happen within the Bitcoin scripting system.
What Are Your Options? When the fork happens your coins will become available on both chains. This is because both chains will share the same blockchain history up until the point the fork occurs. Things are unfortunately not quite as simple as that (when are they ever in cryptoland?). Transactions that would be valid on both chains will occur on both chains. Your transactions will be considered valid on both chains as long as you do not use any of the exclusive features from either ruleset, or use inputs from transactions that are considered invalid on one of the chains. You can alternatively split your coins so that you can control them exclusively on each chain. So what should you do? We won’t recommend what you should do with your own money, and this is not financial advice, but here are some of your options.
Do Nothing and HODL The simplest option is to keep your Bitcoin Cash in a wallet you control and wait for things to blow over. Make sure you have the private keys and or the seed written down in at least one place to be able to recover your funds if needed. As long as you do not move your funds they will be available on both chains after the fork. Risks - Price volatility. Like always the price can go up and down any amount. Only risk what you can afford to lose.
Sell BCH for Fiat Another simple option is to sell your BCH for fiat. This means moving your Bitcoin Cash to an exchange such as Bitstamp.net, Kraken.com or Coinbase, and then selling them for a fiat currency. You may also consider then withdrawing your funds to your bank account for extra security (exchanges have been known to implode with everyone’s funds every now and again). Risks - If the BCH price increase while you hold fiat your BCH holdings will be less if and when you buy back. Exchanges and banks can confiscate your money if they like (that why love Bitcoin remember). By selling you may also be liable for taxes in your jurisdiction.
Split Your Coins and HODL If you want to be ready for anything then you can split your coins after the fork occurs. This means that you will be able to control your coins exclusively on each chain. You will still need to make sure you have your wallet(s) backed up and have the private keys and seeds written down somewhere. To split your coins you can use a tool developed on Electron Cash HERE. This is unfortunately not a simple tool to use right now. Make sure to read the tips and advice given in that thread. You can also use http://forkfaucet.cash/ to receive a tiny amount of split coins to your address(es) so that they will become split once you spend from them. Risks - This has the same risks as simply HODLing your BCH. You should also be aware that some services have decided to refuse to use split coins during the fork. This means that if you send them split coins they will not allow you to spend them. These services include: Yours.org, moneybutton, HandCash, CentBee and CoinText.
Split Your Coins and Sell Some If you interested in gambling on which chain will be more successful you can split your coins using the method above, and can then send coins from either chain to an exchange that allows buying and selling of specific sides of the chain. Most exchanges have decided to close deposits and withdrawals of BCH and even trading of BCH until the outcome of the forks have become more clear. After the fork occurs exchanges will likely make announcements about whether which chain they will support (potentially both), and you will then be able to trade each fork as separate cryptocurrencies. Risks - By selling your coins on one of the chains you will no longer be invested in that side of the fork. In the case that one side of the fork ceases to exist and you are only holding coins on that side, you will have lost that money. By selling you may also be liable for taxes in your jurisdiction.
Summary It is unfortunate that Bitcoin Cash has to go through a fork without unanimous consensus on the new protocol rules. The unique situation with this fork, in particular, has presented some interesting new issues, and it is likely that we as a community will learn a lot from it. We hope that in similar situations in the future that the major entities in the industry, including miners, developers, businesses and community leaders can come together to find compromise that keeps the ecosystem stable and focused on adoption. Further Resources You can get more information at bitcoincash.org, bitcoinabc.org, bitcoinsv.io, and bitcoin.com. If you have further questions about this or just want to discuss the fork in general, we encourage you to join our chat at bitcoincashers.org/chat and join the conversation.
OP_CHECKDATASIG is copying Blockstream, and is inferior to OP_DATASIGVERIFY
Hi all, Bitcoin-ABC's implementation of Bitcoin Cash is set to hard fork on November 18th, activating a bunch of features aimed at enhencing the usability of the currency. One of the proposed improvements is OP_CHECKDATASIG, which can be used to run a verify operation on a (signature, message hash, pubkey) triplet. By itself, this is an extremely useful opcode to have. It allows one to embed an arbitrary message to the transaction, and these messages can then be used in applications external to the chain, or as an way to allow delegated signatures on top of the script itself that is being verified. Pretty cool. OP_CHECKDATASIG is also exceptional for a different reason. In particular, it is an almost exact line-by-line copy of a little-known, yet fairly mature opcode called OP_CHECKSIGFROMSTACK, implemented here : https://github.com/ElementsProject/elements/commit/c35693257ca59b80659cfc4a965311f028c2d751#diff-be2905e2f5218ecdbe4e55637dac75f3R1328 For those who haven't been following, Elements is a project created by Blockstream, and elements alpha is a sidechain where experimental features can be added and tested. This commit from October 2016 shows (among other things) the addition of OP_CHECKSIGFROMSTACK to the elements alpha chain. Compared to the recent addition of OP_CHECKDATASIG to the bitcoin-abc client, the similarity is obvious : https://reviews.bitcoinabc.org/source/bitcoin-abc/change/mastesrc/script/interpreter.cpp;9ba4bfca513d6386ee3d313b15bdd4584da7633d On the other hand, consider Bitcoin Unlimited's OP_DATASIGVERIFY : https://github.com/BitcoinUnlimited/BitcoinUnlimited/commit/1bf53307cab5d96076721ef5a238a63b03aca07d#diff-be2905e2f5218ecdbe4e55637dac75f3R970 This looks more like an independent development. It allows the same functionality as OP_CHECKDATASIG, but it does so in a way which is more transparent and also accessible for normal users. What I mean by that is, recall the verification parameters passed to OP_CHECKDATASIG, these were (signature, message hash, pubkey). For OP_DATASIGVERIFY, the parameters are slightly different: (signature, message, pubkey hash). The difference is subtle, but important. OP_DATASIGVERIFY follows the same design pattern as the widely known signmessage and verifymessage features that are implemented by various wallets (and in use by services like https://vote.bitcoin.com/ ). That is, a raw message is signed for and published by the user to the world, and independent verifiers are able to match the published signature and message to a specific pubkey hash - the data that makes up the user's on-chain address. If you've ever used this message signing and verifying feature of your wallet, you probably know how useful it can be. In contrast, OP_CHECKDATASIG verifies a message hash, not a plaintext message, against a pubkey, not a public address. This means that for a verifymessage-like operation, the script used in the transaction would become quite cumbersome:
We want to publish a plaintext message, but we have to "feed" its hash to OP_CHECKDATASIGVERIFY, so we have to use an OP_HASH256
The pubkey we provide for verification will be "used up" by OP_CHECKDATASIGVERIFY, so we must both duplicate it and keep the copy in altstack
OP_CHECKDATASIGVERIFY behaves exactly like OP_CHECKDATASIG, except that it fails the entire script immediately if the signature fails to verify
We have the pubkey, but we still have to check that its hash matches the address, so we use OP_HASH160 and test for equality. Note that this means that we have to publis both public key /and/ its hash in the same transaction. Almost too wasteful.
Using OP_DATASIGVERIFY instead, the script is simply:
Hashing of the plaintext message is done internally by the OP_DATASIGVERIFY operation, and the same is also true for the hashing of the resulting public key against the provided pubkey hash (the data that makes up the address). A second not-so-obvious difference is the actual content of in the two scripts. For the OP_DATASIGVERIFY script, this message is actually parsed and verified using the exact same format as verifymessage in the wallet. This means that services like blockchain explorers can then simply decode the data in such a transaction and present it to users in a manner that enables them to run local verification of the message using their own wallet, simply by copy+pasting the information! Using OP_CHECKDATASIG instead, the does not follow the same semantics and format as the one in verifymessage, and no wallet exists today which support such a verifying operation in the UI. It is also hard to expect something like verifydatasigmessage to be implemented on absolutely all wallets. I think it benefits of OP_DATASIGVERIFY when measured against OP_CHECKDATASIG are obvious, and am curious to hear your opinions.
Colin gives a rundown on Nexus layered architecture
This is an excerpt from a much larger impromptu Q&A on Nexus Telegram, and provides an excellent overview of Nexus architecture. (edited for clarity) --------------------------------------------------------------------- Paul Screen, [10.09.19 22:03] [In reply to CryptoJoker] yes it is. There's no question that ethereum and it's direct competitors that offer turing-complete programmable contracts are very powerful. But when you actually look at the requirements of businesses trying to onboard to blockchain, we found that most of them just need simple requirements met and don't need all of the complexity and baggage that comes with it. CryptoJoker, [10.09.19 22:04] [In reply to Paul Screen] ok so ca u run only simple multi conditional transactions on the nexus VM or facebook type DAPPs on nexus ? Viz., [10.09.19 22:09] [In reply to CryptoJoker] Nah the VM is the interpreter so the language fits on top, we haven’t designed nexus to be a programming language this is an approach we didn’t agree with. It is APi based so you can code in any language and work with the functionality of the blockchain layer for what you need it to do. No you can’t port EVM code into Nexus CryptoJoker, [11.09.19 00:22] [In reply to Viz.] when you make an api request, does this result in computations done on the blockchain ? Viz., [11.09.19 00:23] It depends on the API request, if you do let’s say users/list/notifications then no as this is reading data, but finance/credit/account would since it broadcasts a transaction with OP::CREDIT CryptoJoker, [11.09.19 00:24] [In reply to Viz.] ok thanks , and can you provide me an idea of the flexbility of the VM on nexus ? can it run like facebook type dapps for example ? Viz., [11.09.19 00:28] It depends, it depends on what you want the blockchain to do and don’t. Dapp is an overused word and overstated in capability because a blockchain isn’t a computer and shouldn’t ever be, it’s a verifier. So, if you wanted to make a social network on nexus, trade tokens, chat, sure you could. A lot of functionality will be in the logical Layer as there’s no point to compute let’s say an image compression on the blockchain, you would on the logical Layer compress it, hash it, then build an object Register to hold the meta data associated with it that includes the checksum, include description. Then to update, you change the state in the object register, etc. If you wanted to do conditions in some of these interactions you could program the Boolean expression in such as, I’ll sell you this object for 5 NXS, someone is able to claim the transfer based on the condition of their debit, so on. CryptoJoker, [11.09.19 00:29] [In reply to CryptoJoker] how does the functinonality of the nexus scripts compare to that of bitcoin scripts ? is it fair to assume this: bitcoin scripting < nexus scripting < ethereum type smart contracts ? it seems like its mostly built to handle only transactions ... Viz., [11.09.19 00:31] [In reply to CryptoJoker] Not really, our architecture is completely different, hard to compare functionality. Let’s just say bitcoin scripts are slow, clunky, and stack based and only handle a Boolean expression to spend inputs, ours is a register based system with primitive operations and conditions that all interact to provide contract functionality Viz., [11.09.19 00:31] [In reply to CryptoJoker] You miss what the term register means then And “programmable data structures” CryptoJoker, [11.09.19 00:31] [In reply to Viz.] yes, this is the first time i am encountering this i also dont have a programming background unfortunately Viz., [11.09.19 00:33] A register is a structure that on hardware is what your cpu uses to store numbers in low latency memory (close to the CPU in its internal cache).... hang on, switching to computer... CryptoJoker, [11.09.19 00:34] [In reply to Viz.] ok this is all fine and good, but i guess for a layman like me i just wanna know what its functionalities are in comparison to EVM type VMs ... what can it do in comparison to EVMs, and is it fasteslower, more expensive/cheaper ? Viz., [11.09.19 00:36] Let me explain it like this: Ethereum is like everything put in one bucket, it has a turing complete byte code because they imagined you could program it like a universal computer. The reality is though, that most people abstract away from the EVM and use it for pure data storage, or managing accounts and tokens. They include operations like EXP for example, and use what is termed "Big Numbers" which are numbers that are in the range of 2^256 which is a number with over a hundred zeros. This has led to significant bottlenecks, and little value in being turing complete even though this was their value propositiion. Viz., [11.09.19 00:36] Now we get to Bitcoin, which was deliberatly not turing complete, and its scripts were designed to control the conditions on spending inputs in the UTXO model, in which it has proven useful, and some scripts such as OP_RETURN have allowed people to store data on it, but then again it aws not useful for much more than that. Viz., [11.09.19 00:37] Then we get to us, think of us between bitcoin and ethereum, but building contracts to act like contracts between people, rather than computer code. Viz., [11.09.19 00:41] So think of us as a blend of the two concepts, but in a way that is practical and useful for developers. From my research of talking to many companies that were using blockchain, I deduced a simple common denominator: nobody used ethereum for the turing completeness, they used it to store data. This was the foundation of the architecture that I developed for tritium that is a seven layer stack. So I'm going to break this down, and hope this communicates how it functions to create smart contracts or dapps in just about any capacity that's needed: Viz., [11.09.19 00:41]
Network - this is responsible for end to end communication between nodes, handling the relaying and receiving of ledger level data
Viz., [11.09.19 00:43]
Ledger - this is responsible for ensuring all data is formed under consensus and is immutable by nature. This is where your 'sigchain' or blockchain account exists. A sigchain is a decentralized blockchain account that allows you to login from any node with a username, password, and pin without the need for wallet.dat files or constantly rescanning the database. This is an important piece to how the layers above work as well, think of it as a personal blockchain that allows decentralized access through the login system that does not store any credentials, but rather deterministically creates a 'lock' mathematically that only your credentials can unlock, using a few different cryptographic functions I won't name here
Viz., [11.09.19 00:46]
Register - this layer is the data retention layer, or the layer that stores information relating to users. A register takes two forms: state and object. A state register is jsut a simple register that can store data in any sequence with no formatting enforced by the ledger. This would be for applications that have a state they want to remain immutable whih they can record in a state register. The second form is an object register, which is a programmable data type. What this means is that I can specify the fields of this register, and set some of the fields to be mutable or immutable such as lets say S/N would be immutable, but notes mutable. This allows objects to take the form much like a struct or class in object oritented languages, that can be accessed by any node, and only written to by the owning sigchain. Now registers sit on top of the ledger, and they can be transferred between sigchains or users, allowing them to take a natural form as assets or simple objects that would be included in a decentralized application such as a crypto kitty, or a post yoj make on social media, etc. This layer is responsible for managing all these states and ensuring the specified fields in these states are immutable, while other fi9elds can be updated like a program would do as it operates.
Viz., [11.09.19 00:51]
Operation - this layer is what gives context to a register and causes some action to take place. It includes two aspects to this layer, Primitive operations and Conditional operations. A contract object is a self contained object containing: a register pre-state (the register that is being operated on), a primitive operation (only one primitive operation per contract), and a set of conditions (any amount of conditional ops may be used for a fee of course). The primitive operations are basic ones like WRITE, APPEND, DEBIT, CREDIT, TRANSFER, CLAIM, CREATE, AUTHORIZE, TRUST, CONBASE, GENERATE. Each of these has a specific operation on the register it is initiated in. This is how you would maintain the state of a decentralized app, lets say crypto kitties, you have an object register that you create with OP::CREATE that has a specific meta data format associated with it, you then OP::TRANSFER it to someone else, but you gie a condition saying they must send 500 NXS beforehand, and this is the stiuplation of the TRANSFER being CLAIMABLE. When this ondition is satisfied you are able to claim the other point allowing for forms of exhange. Other stipulations or conditions could be arbitration, escrow, etc. Conditions are when there is an interaction between two actors or sigchains, which happens with a DEBIT or TRANSFER. Otherwise the other primitive oeprations act on the register such as changing its state.
Viz., [11.09.19 00:52]
API - This layer is responsible for giving an interface for the programmer to build their DAPP. This gies them direct access to login, create registers, create accounts, send coins, read data, manage notifications, etc. This is the layer develoeprs will interact with when building applications.
Viz., [11.09.19 00:53]
Logical - This is the first 'developer' layer, menaing that this is the layer that will give most of the logic to the application. This coudl be simple things like, send message to this user if they have this object that has a value of 'you're my friend' ,or antything else. This layer is the 'backend' of the dapp, and what provides a lot of the functionality. States can be read and written into the register layer, information from the ledger can be shared, stipulations on interactions can be applied. etc.
Viz., [11.09.19 00:54]
Interface - This is the 'user' layer, where the user will interact with. This in the facebook example would be the website you go to, and all the buttons that do fun stuff. This is the last layer of the 'developer' application space.
CryptoJoker, [11.09.19 00:54] thank you big applause!!!! CryptoJoker, [11.09.19 00:56] ok so to summarize my understanding of this 3 allows for creation and transfer of digital assets/objects 4 governs the operations that on objects in 3 5 interface between dapp logic and registeoperations layer
this is where the "dapp" is written by developers
am i right ? Viz., [11.09.19 00:57] So as you can see, all these layers together are what form the foundation of a dapp, with the blockchain doing some things, the application does other things. They togheter give the blockchain scability and easy to build on, and also give the appliation powerful tools to utilize. For example of an object register, your NXS account. It contains fields identifier and balance. The identifier identfies the token's contract-id or object register, and the balance keeps track of how much you have at stake. Object registers can be polymorphic though, so you can create an object register with tehse two base types, but add, notes, which you could fill with personal notes and the DEBIT and CREDIT operations would process it off of the base object, or the account menaing that you can expand from these basic objects and create many different types and uses, creating object oriented and polymorphic behavior Viz., [11.09.19 00:57] 3 is simply where they are store, it takes 4 to create the object 5 yes 6 yes plus 7, the dapp space is layers 6 and 7 together. If the dapp developer is really good though, they make custom API's with more complex contracts under the hood to provide additional functionality to their dapp, but we currently abstract the developer away from this to prevent them making mistakes that could lose people a lot of money CryptoJoker, [11.09.19 00:59] whereas for the EVM, 3,4,5,6 and 7 are all bundles into one entitiy, am i right ? Viz., [11.09.19 00:59] And last note, on layer 4, the conditional statements. These also operate on a register based VM that processes the conditional statements, and they can be grouped with as many different conditions as desired, so they can grow into quite complex contracts like we would see with legal contracts. Viz., [11.09.19 01:00] EVM doesn't really have layers It's just EVM opcodes, and then the compiler for solidity which creates the byte code, so maybe two layers Same with bitcoin scripts But bitcoin scripts dont have a compiler that creates the byte code so you have to program it as a type of assembly Viz., [11.09.19 01:01] So long story short is, our techniques and architecture are quite unique, and designed around years of market research to ensure that it was built as something that people could use easily, but also powerful enough to power the dapps people want to see Viz., [11.09.19 01:03] The login account is really important for adoption in my opinion, because users having to manage keys wont bode well for applications that expand, lets say like supply chains or other mobile applications. Managing keys in a file on your computer I think is a big hurdle to mainstream adoption, the other one is the complexity of EVM and how little practical appliation it has, even though it contains a lot of functionality, most of it us unused or abstracted away from
I did it as a tribute to our missing Satoshi: we are missing Satoshi, and now the blockchain is missing 1 Satoshi too, for all time.
EDIT: Users have pointed out in the comments that this isn't actually the only time coins have been destroyed, there are actually several different ways coins have been destroyed in the past. sumBTC also points out that the satoshi wasn't destroyed-- it was never created in the first place. Another interesting way to destroy coins is by creating a duplicate transaction. This is again done with a modified client. For example see block 91722 and block 91880. They both contain txid e3bf3d07. The newer transaction essentially overwrites the old transaction, destroying the previous one and the associated coins. This issue was briefly discussed on Github #612 and determined to not be a big deal. In 2012 they realized that duplicated transactions could be used as part of an attack on the network so this was fixed and is no longer possible. Provably burning coins was actually added as a feature in 2014 via OP_RETURN. Transactions marked with this opcode MAY be pruned from a client's unspent transaction database. Whether or not these coins still exist is a matter of opinion. Finally, at least 1,000 blocks forfeited transactions fees due to a software bug. Forfeited transaction fees are lost forever and are unaccounted for in any wallet.
Between block 162705 and block 169899, 193 blocks claimed less than allowed due to a bug, resulting in a total loss of 9.66184623 BTC.
Between block 180324 and block 249185, another 836 blocks claimed less than allowed, resulting in a total loss of 0.52584193 BTC.
I was reading about 0-conf, this paper explains the new opcodes that were added to BCH abc OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY. these allow sending 0-conf transactions with more security to not allow a double spend, replace by fee is also removed in BCH to add security. More about that here: https://gist.github.com/awemany/619a5722d129dec25abf5de211d971bd This works for BCH since the blocks are so large, that setting a very low fee should not impact the transaction going through. or is it possible to set a fee that is less than the byte size of the transaction? would this be rejected by miners? As to bitcoin, they are opting for lightning network instead. With LN i've read that block sizes would need to scale to 133mb+ to allow enough scaling of channels with mass adoption, this figure comes from 1 person in the world opening 1 channel with someone else, 6 billion people, was taken as the estimate, but i think the smaller subset of people using btc will open more channels than people anticipate. It seems like btc is stuck with having to increase block sizes eventually, why the resistance? To me 0-conf looks like a better solution than LN for the scaling issues alone since LN requires an entry into the blockchain anyway to open a channel. LN requires two people to be online at the same time, 0-conf does not. Hubs could become centralised due to liquidity requirements. as UTXO goes through nodes, the UTXO is encumbered at each node, it is essentially loaned out. If i start a LN node with 0.5btc, realistically will i get any traffic? or will wallets gravitate to LN hubs with large stores of BTC that regular people could not fund? If the above is true, LN doesn't scale, due to needing to increase the block size to huge sizes, which also increases mining centralisation as latency will play a key role. The top miners are on extremely fast internet connections to ensure they are not mining stale blocks. It also raises the concern of centralisation of LN hubs. Seems like fixing BTC with bigger blocks and 0-conf without replace by fee as is done in bitcoin abc would be a better solution than LN. Thoughts? edit: to people who think im some BCH shill, i dont own either and i dont like payment coins, im just interested in the tech decisions made to help scaling and speed. my stance on payment coins is obvious re: https://www.reddit.com/CryptoTechnology/comments/8ank7g/do_any_of_you_foresee_a_crypto_being_widely/
New Electron Cash coinsplit tool with support for both OP_CDSV and OP_MUL released!
Here (source only, for now): https://github.com/markblundeberg/coinsplitter_checkdatasig/releases/tag/3.3.1CSplus There has been a lot of focus lately on the opcode OP_CHECKDATASIGVERIFY which can be used to make ABC-only transactions -- a property used in the previous release of my coin splitting tool. In the spirit of Electron Cash's support of both chains, today I'm releasing an update that helps you use an SV-only opcode, OP_MUL. I strongly suggest that only experts use the OP_MUL tool, for technical reasons:
The MUL variant of the splitter is slightly less flexible in that disabled opcodes prevent creation of a 'refund' branch in script. So, the 1000 satoshis you send to the splitting contract will be semi-permanently unspendable on the ABC chain, until a future date when OP_MUL gets enabled.
By carefully using both the CDS tool and the MUL tool, you can create a full two-way split that lets you immediately start transacting on both chains without fear of replay attacks. However,doing this in a properly attacker-immune way will require a deep understanding of the UTXO aspect of bitcoin.
See previous announcement and user guide for more info. Note: Most users who want to split coins do not even need to use coin splitting tools like this, and can obtain already-split coins from many services such as cryptocurrency exchanges. I have released this tool mainly to help advanced users (including exchange operators) to control their coins independently of other services. Edit: documentation has been updated to describe how to split coins on non-standard (hardware / cold) wallets and non-Electron-Cash wallets.
Strange errors in the Blockstream Liquid, announcement post
If you don't fancy reading my post below, you can instead, listen to it here. Liquid is claimed to be the "world’s first production Bitcoin sidechain". It's an off-chain transaction system. You don't transact BTC on Liquid. Instead, you transact with representative tokens called L-BTC. This is a bit like how USDT (Tether) aren't real US dollars, they're representative tokens. The following is a paragraph from from the announcement post. I have highlighted the errors in bold:
In addition to the enhancements to Bitcoin’s functionality\1]), the launch of the Liquid Network marks the beginning of a new era of digital asset issuance and transacting by enabling the tokenization of fiat, gold, securities, and even other new crypto assets – all with Bitcoin at the center\2]).
Error 1: "enhancements to Bitcoin’s functionality"
Contrary to the claim: "Bitcoin" hasn't been enhanced by Liquid. If you enhance an off-chain system (e.g. a centralized exchange, a tipping app, a payment channel network or a side chain), you are not "enhancing Bitcoin", you are enhancing the off-chain system that is using Bitcoin. If I modify my car engine to enhance the performance, you wouldn't say that I have "enhanced the road". If I improve an algorithm in a game I had written to allow the game to render more smoothly, you wouldn't say that I have "enhanced the game console". If Rocketr enhance the their reddit tippr bot, you wouldn't say that they have "enhanced Bitcoin Cash". This may not be an accidental error on Blockstream's part. It may be another data point in a pattern of deception emanating from Bitcoin Core developers and supporters. They often conflate systems built on-top of BTC with BTC itself. I'm sure many of you have heard BTC users claiming "Lightning is Bitcoin" or "Lightning transactions are Bitcoin transactions". This appears to be more of the same; IE Liquid is an enhancement to Bitcoin. These people appear to want people to believe that Bitcoin is a centrally managed, partially-AXA funded, side-chain project (among other things). So here are some actual examples of real enhancements to Bitcoin:
In May of 2018, 6 op codes were renabled and a new one (OP_SPLIT) was added to Bitcoin (BCH). source, source.
Also in May of 2018, Bitcoin's (BCH) on-chain transaction processing capacity was increased by increasing the miner-consensus, block size limit from 8 MB to 32 MB. This allows more people to use the system.
Again in May of 2018, the OP_RETURN relay size was increased to 223 total bytes. This has made it possible to use Bitcoin (BCH) for more purposes than were previously possible. You can now store more arbitary data in a single transaction. Memo.cash is one such service taking advantage of the increased OP_RETURN space. BitDB2 also provides a convenient mechanism to allow for the creation of novel apps that utilize this extra space.
In November of 2018, Bitcoin (BCH) is likely being enhanced with 2 new op codes: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY. These op codes combined with the previously mentioned string processing OP codes allow Bitcoin (BCH) to gain some of the power of Ethereum. They enable Bitcoin scripts to get information from outside the blockchain. For example: you will be able to easily make a betting application using Bitcoin script where the outcome of the bet is reported by a source or set of sources external to the blockchain and the Bitcoin script decides who wins the bet based on that data. You can learn a little more about this by reading this article by Andrew Stone (A Bitcoin Unlimited developer).
Error 2: "all with Bitcoin at the center"
"Bitcoin" is not in the center... "Bitcoin" is off to the side (literally). There is no economic revolution happening on the BTC chain. The genius and evolutionary Bitcoin technology has been systematically constrained, limited and shoved off to the side. The vision that Blockstream, Bitcoin Core, Greg Maxwell, Adam Back, Samson Mow and others have for your monetary future is one where the Bitcoin technology is reduced to being a settlement system for corporations and the super-rich: IE people that can afford to pay the high fees on their artificially constrained system. BTC users may be unable to afford to transact on the artificially constrained BTC system due to the intermittent high fees. These users may be unable to use the trust-less Lightning Network due to the fact it's only suitable for "small or micro value payments" (source) and it is impractical and has a poor user experience. Blockstream helped to create these problems and they conveniently offer up the solution: Liquid. Blockstream see Liquid as a suitable system for use by end-users using wallets like the Blockstream GreenAddress wallet. Is BTC too slow and expensive for you? No worries! Try Liquid! The whole system is securely maintained by government licensed, centralized currency exchanges that pay a recurring monthly fee to Blockstream. Liquid is the financial system of the future that Satoshi could only dream of! /s
My Suggested Correction To The Article
I have reworded the offending paragraph to correct the errors and more honestly represent Blockstream:
As part of a well-organised, ongoing effort to move Bitcoin’s functionality into inferior, permissioned or trusted off-chain systems, the launch of the Liquid Network brings humanity one step closer to complete monetary enslavement. Bitcoin; a peer-to-peer, electronic cash system; was a tool created-to, and promoted-as a system to give humanity sound money, prosperity and economic freedom like never seen before. Liquid is just one part of a multi-pronged approach to take that system and re-purpose it to serve the will of the existing financial oligarchs.
Blockstream: feel free to update your announcement post and use my corrections, verbatim. No charge.
Why is Bitcoin Cash better than a big block privacy coin like Monero? Serious responses please.
I am a huge supporter of the hard fork that created Bitcoin Cash. It is the best demonstration of the potential of Bitcoin's white paper approach while also innovating. Reliable 0-confirmations, reliable and inexpensive confirmed transactions. What is not to love? However, surely for transactions everyone is going to want privacy? Corporations, institutions, the wealthy, and even the not wealthy, don't want their transactions to be soduko puzzles for government surveillance and hackers to mine. I will start with two BCH advantages over XMR:
Apparently Supporting XMR is technically more difficult for wallets and other tools.
The tremendous media and social hype around the word "Bitcoin" not only raises the public's consciousness of BTC but to a lesser extent BCH.
These seem like temporary advantages to me. Any other serious advantages of BCH vs XMR or other privacy coins? Or vice versa? EDITS: ======= FROM COMMENTS, TEXT ABOVE AND REFERENCES WITH LINKS ======== Advantages for BCH:
Supporting BCH with wallets and other tools is technically easier than for XMR.
The tremendous media and social hype around the word "Bitcoin" and BTC also raises the public's consciousness of BCH.
BCH transactions take up less space than XMR, making BCH ledger more scalable.
XMR's reputation as criminal friendly may create political/regulatory pushback.
BCH has already been adopted by more merchants.
More on chain scriptability than XMR.
XMR wallets need the whole ledger. BCH wallets can efficiently update with targeted queries.
The longer history and greater resources behind BCH result in better user interfaces and other related tools than for XMR.
BCH fees are lower than XMR fees. (Although XMR fees are likely to drop with more usage.)
Advantages for XMR:
XMR has far stronger privacy than BCH. BCH coinjoin services are available but much weaker.
XMR privacy is mandatory and consistent, as opposed to voluntary methods like coinjoin services.
XMR's blocks are created every 2 minutes, so confirmation times of block inclusion are faster. (Although reliable 0 confirmations for BCH may be fastest in practical terms for smaller transactions.)
XMR funds are free from tainting which in BCH/BTC can result in funds being locked by exchanges due to association with gambling or other undesired histories.
Apples and Oranges: Block reward schedules vs. Inflation schedules BCH has a maximum quantity that can be minted, as block rewards are drawn down toward zero. So BCH is rapidly reaching zero inflation, but also very small block rewards. XMR takes a different approach with block rewards eventually being constant every year, so they will always exist while letting the inflation rate drop every year, eventually becoming negligible. Relevant BCH improvements in progress:
Graphene in preparation for greater scaling with sharding and parallelized block validation.
Opcode work for future support of colored coins and other tech.
Efficient range proofs for RingCT to improve scaling with smaller transaction sizes.
Kovri private IP2 routing.
Bottom Line? Each coin provides different valuable features. Neither coin looks in danger of matching the other coins best features any time soon. Thanks for all the informative, insightful and constructive comments!
As a reminder, the reason to support SegWit is because it is clearly the best blocksize limit increase proposal, based on technical merit, not because of who proposed it. SegWit is the fastest and least disruptive onchain capacity increase proposed
SegWit will result in an effective onchain capacity increase of c110%, current Bitcoin fees are skyrocketing and a capacity increase is now desperately needed. The methodology used to increase capacity is literally increasing the amount of data per block, so that it is higher than the current 1MB limit. Contrary to some of the misinformation going around, SegWit does not increase capacity by improving efficiency, the only way capacity improves is by increasing the blocksize.
SegWit is a faster onchain capacity increase than all other blocksize limit increase proposals. Some may argue that SegWit is slower than a “simple hardfork to 2MB blocks”, but this assumes a faster user upgrade to the “simple 2MB hardfork” client than for the SegWit client, this is a spurious comparison. On a like for like basis (for any given level of user upgrades), SegWit is a faster and larger capacity increase than a "simple hardfork to 2MB".
SegWit can provide individual users an almost instant 80% fee reduction, after activation, even if no other wallets upgrade. After SegWit activates, a single user can upgrade to SegWit and their wallet will automatically segregate the witness in their own transactions, no matter what other users do, this will result in 80% lower fees, assuming all else remains equal. This almost instant benefit, is far superior to any other capacity increase proposal.
With SegWit, upgraded wallets and non upgraded wallets can seamlessly transact with each other, unlike almost all other blocksize limit increase proposals
If 51% of miners support SegWit, we will avoid a chainsplit and the creation of a new coin, unlike almost all other blocksize limit increase proposals.
Third party transaction malleability fixes
Unfortunately due to a bug in Bitcoin, when users send a transaction, anyone on the network can change the transaction ID, which could be the transaction that ends up getting confirmed in the blockchain. This means that if a user receives a Bitcoin transaction, it is often not reliable or safe to forward these funds on to somebody else, before the incoming transaction receives a confirmation. This is a huge problem for the user experience and sometimes results in users waiting around for confirmations, which can take longer nowadays due to full blocks. SegWit fixes this bug, allowing users to send transactions without exposing themselves to this risk. Additional advantages of this fix is that it makes implementing wallet software far easier and makes implementing payment channel technologies like the Lighting Network easier.
Fixing the quadratic scaling of sighash operations bug, making a further bocksize limit increase both safer and more likley
Unfortunately, due to another bug in Bitcoin, as transactions gets larger, the amount of hashing required to verify the signatures increases in a quadratic way. For example doubling the size of a transaction can increase the verification time by a factor of 4. SegWit fixes this bug by allowing users to create transactions with linear scaling of sighash operations. Many people in the community oppose a “simple hardfork to 2MB” on the grounds that this could open up an attack vector, where a would be attacker could exploit this bug and produce hard to validate blocks. Fixing this bug therefore makes a further blocksize limit increase after SegWit both safer and more likely.
Signing of input values, making Bitcoin easier for hardware devices
SegWit allows users to create transactions where the input value is hashed. This means hardware wallets can spend a transaction without needing a copy of all the input transactions and needing to hash these inputs. This makes hardware wallets much easier to develop and it makes it easier to use Bitcoin on smaller embedded devices
Not requiring wallets to download the signature data to check the transaction hash
After SegWit, wallets will no longer need to check the signature data to check the transaction hash. This means light wallets can avoid downloading more of the signature data. This improves the scalability of the network and makes further blocksize limit increases safer.
Introducing script versioning makes upgrades to increase onchain capacity even further far easier
SegWit adds a version number for scripts, this means new opcodes that would have required a hardfork, can now be added by changing the script version. For example more efficient signature schemes like Schnorr signatures can be added, which would further increase onchain capacity.
As a hard fork war is imminent and because Coinbase is freezing its BCH activity in anticipation of a chain split, /GlobalOffensiveTrade will be suspending all Bitcoin Cash trading tonight at 6 PM CST (0000 UTC) until further notice.
Posts involving Bitcoin Cash trades will be removed by AutoModerator after this time. You should also be aware that exchanges like Coinbase may experience increased load from people taking action and offloading coins into wallets they directly control in advance of a potential fork, which has the potential to result in processing delays. If you use Bitcoin Cash, chances are that you may have already heard about this upcoming war and know what to do and have already plotted your course of action. But for those that haven't, we recommend avoiding non-essential Bitcoin Cash trades through the next few days. If you wish to get out of Bitcoin Cash by way of liquidation to a fiat currency or an alternative cryptocurrency of choice, or if you want to remain with Bitcoin Cash and prepare to place your vote on what the wider ecosystem will back, now is the time to do so. "OG" Bitcoin is unaffected and will not be suspended, so you will be able to continue to post BTC trades without interruption (as long as your trade doesn't also list BCH). And as a reminder, our bait-and-switch policies involving Bitcoin is as follows: if you do not explicitly specify which variant of Bitcoin you want, it will be assumed that you want original Bitcoin and not Bitcoin Cash (including if you say just BTC). If you want Bitcoin Cash instead of original Bitcoin, you must explicitly say so, either by stating "Bitcoin Cash", "BCC", or "BCH". As the hard fork war progresses, the health of the Bitcoin Cash network(s) will be evaluated periodically. Chances are that if Coinbase comes to a decision, we will make ours as well and resume when that happens.
The figure above shows the main parts of a Bitcoin transaction. Each transaction has at least one input and one output. Each input spends the satoshis paid to a previous output. Each output then waits as an Unspent Transaction Output (UTXO) until a later input spends it. When your Bitcoin wallet tells you that you have a 10,000 satoshi balance, it really means that you have 10,000 satoshis ... I don't think there is a command you can run, besides looking at Bitcoin's source code. (look for enum opcodetype). Note that a lot of the opcodes listed there. are disabled to reduce complexity, (OP_CAT)change meanings depending on which softforks are applied, (OP_CHECKLOCKTIMEVERIFY and OP_NOP2 have the same opcode) or may have no meaning in a script. So although one can have a Bitcoin wallet using a personal computer, Bitcoin transactions are mined with much more computationally robust computers. ... The same way it is possible to add another signature to the script, verify can be added to the sequence of opcodes. All Bitcoin transactions are self-contained, so while the transaction itself ... Bitcoin Wallet. Unlike a bank, Bitcoins are not tied to users or accounts. Instead, Bitcoins are owned by a Bitcoin address, ... Using hex codes for above opcodes in locking script results in - Opcodes. This is a list of all Script words, also known as opcodes, commands, or functions. There are some words which existed in very early versions of Bitcoin but were removed out of concern that the client might have a bug in their implementation.
Guide to the Best Bitcoin Wallets of 2019 - YouTube
Bitcoin Vault is developed to provide an extra level of security based on a three-private-key security structure. It features all the convenience of Bitcoin ... Here are two BIP drafts that specify a proposal for a Taproot softfork. A number of ideas are included: * Taproot to make all outputs and cooperative spends indistinguishable from eachother ... How to send bitcoins from any address by exploiting the coin value 🔥 TOP Crypto TIPS In My Weekly Newsletter 👉 https://signup.coinbureau.com/newsletter 🛒 Get A Ledger Nano - My Top Safest Wallet Pick 👉 https://guy ... How to Setup a Bitcoin Wallet- https://bit.ly/mydigitalfinance Hi guys you've landed on this video because you searched for how to setup a bitcoin wallet. In...