HOW TO: Write Custom Bitcoin Scripts in Bitauth IDE ...

Why was this video on Bitcoin Cash banned from Youtube?!

Watch the new episode of the Weekly News Show with Roger Ver here:
Find out why you are not watching this Weekly News Show episode on YouTube; how did the recent BCH Upgrade go, and more about NFC payments with BCH on!
►►►Hit the follow button to subscribe to our channel:
0:05 - BCH Upgrade Complete: 3 New Features Added to Consensus Rules
1:05 - Thoughts on the ‘Bitcoin - Unmasking Satoshi Nakamoto’ video
2:00 - There is an attempt to rewrite the history of BCH
2:53 - The average Bitcoin transaction fees are high again
3:01 - YouTube gave a strike to the - Official Channel
3:47 - There's more Bitcoin on Ethereum than in the Lightning Network
5:20 - NFC payments with Bitcoin Cash on
Links: ►BCH Upgrade Complete: 3 New Features Added to Consensus Rules:
Unconfirmed transaction chain limit has increased from 25 to 50. New opcode support, and improved counting of signature operations were also added.Source:
►Watch ‘Bitcoin - Unmasking Satoshi Nakamoto’:
►Follow btc for open and free discussions on Bitcoin:
►Check the average next block fees of BCH and BTC:
►Watch our video banned banned from YouTube at
‘What do miners think about the Mining Pool?’:
►There's more Bitcoin on Ethereum than in the Lightning Network:
►NFC payments with Bitcoin Cash on the register app:
►Original Tweet:
►Are you a developer? Change the world with Bitcoin Cash:
Follow our other social media channels:
►Visit our main website at:
►Download our free Bitcoin wallet:
►Buy Bitcoin or Bitcoin Cash with a Credit Card:
►Discover merchants accepting BCH near you:
►If you’re a merchant and want to accept BCH visit:
►Download the Bitcoin Cash Register App here:
►Get instant privacy with CashFusion:
►Visit our Developer site and help change the world:
►Get the latest crypto-related news:
►Shop our merch at the Store:
►Find and join our mining pool here:
► Listen to our Podcast on these platforms:
submitted by SweetSweetCrypto to btc [link] [comments]

The Goal of

“The goal of 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). 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, and is one we want to keep front of mind, it is only one cog in the many wheels that keep driving the industry forward.”
-- Roger Ver
submitted by MemoryDealers to btc [link] [comments]

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: 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 ( We'll get better support of that as well as dual-funding, splice-in and splice-out (
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 ( 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 ( 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:
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 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 ( 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 (, 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 (, making eltoo ( possible, and blurring the lines between layer 1 and layer 2 (
That'll make lightning even more usable and allow more advanced layer 2 contracts like channel factories (
All these advanced features will require greater wallet interoperability. That's where 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 ( or some other covenant-enabling opcode will be activated, allowing richer layer 2 constructions like joinpools (
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. is a great place to start.
2020 is going to be a great year for Bitcoin and Lightning protocol development!
submitted by TheGreatMuffin to Bitcoin [link] [comments]

Proposal for May 2019 upgrade: add Schnorr signatures! Let's discuss.

Proposal for May 2019 upgrade: add Schnorr signatures! Let's discuss. submitted by markblundeberg to btc [link] [comments]

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:
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:
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:qrsplterpal0qx0ncerywfq2m7rjmyle3vzcektucc before 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.
submitted by markblundeberg to btc [link] [comments]

Why was this video on Bitcoin Cash banned from Youtube?

Watch the new episode of the Weekly News Show with Roger Ver here:
Find out why you are not watching this Weekly News Show episode on YouTube; how did the recent BCH Upgrade go, and more about NFC payments with BCH on!
►►►Hit the follow button to subscribe to our channel:
0:05 - BCH Upgrade Complete: 3 New Features Added to Consensus Rules
1:05 - Thoughts on the ‘Bitcoin - Unmasking Satoshi Nakamoto’ video
2:00 - There is an attempt to rewrite the history of BCH
2:53 - The average Bitcoin transaction fees are high again
3:01 - YouTube gave a strike to the - Official Channel
3:47 - There's more Bitcoin on Ethereum than in the Lightning Network
5:20 - NFC payments with Bitcoin Cash on
Links: ►BCH Upgrade Complete: 3 New Features Added to Consensus Rules:
Unconfirmed transaction chain limit has increased from 25 to 50. New opcode support, and improved counting of signature operations were also added.Source:
►Watch ‘Bitcoin - Unmasking Satoshi Nakamoto’:
►Follow btc for open and free discussions on Bitcoin:
►Check the average next block fees of BCH and BTC:
►Watch our video banned banned from YouTube at
‘What do miners think about the Mining Pool?’:
►There's more Bitcoin on Ethereum than in the Lightning Network:
►NFC payments with Bitcoin Cash on the register app:
►Original Tweet:
►Are you a developer? Change the world with Bitcoin Cash:
Follow our other social media channels:
►Visit our main website at:
►Download our free Bitcoin wallet:
►Buy Bitcoin or Bitcoin Cash with a Credit Card:
►Discover merchants accepting BCH near you:
►If you’re a merchant and want to accept BCH visit:
►Download the Bitcoin Cash Register App here:
►Get instant privacy with CashFusion:
►Visit our Developer site and help change the world:
►Get the latest crypto-related news:
►Shop our merch at the Store:
►Find and join our mining pool here:
► Listen to our Podcast on these platforms:
submitted by SweetSweetCrypto to Bitcoincash [link] [comments]

Urbit meetup in North Texas

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.

For TheMotte

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.

Further reading:

submitted by p3on to TheMotte [link] [comments]

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.

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. submitted by Falkvinge to btc [link] [comments]

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.
submitted by akimotoz to btc [link] [comments]

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:
  1. One address has a relative timelock condition - any funds sent to this address can only be spent after 1 week with private key 1.
  2. 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:
  1. Address 1:
    • Can be spent by Key1, Key2, or Key3.
    • Requires funds are sent to address 2.
  2. 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?
submitted by fresheneesz to BitcoinDiscussion [link] [comments]

Upcoming Updates to Bitcoin Consensus

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.




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.




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.




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.



submitted by almkglor to Bitcoin [link] [comments]

You can call you a Bitcoiner if you know/can explain these terms...

10 Minutes
10,000 BTC Pizza
2016 Blocks
21 Million
210,000 Blocks
51% Attack
Asic Boost
Bitcoin Cash
Bitcoin Improvement Proposal (BIP)
Bitcoin SV
Block height
Block reward
Bloom Filter
Brain Wallet
Change Address
Child pays for parent (CPFP)
Coinbase (not the exchange)
Coinmarketcap (CMC)
Colored Coin
Custodial Wallet
Craig Wright
David Kleinman
Difficulty adjustment
Difficulty Target
Dorian Nakamoto
Double spend
Elliptic Curve Digital Signature Algorithm (ECDSA)
Full Node
Gavin Andresen
Genesis Block
Getting goxed
Hard Fork
Hardware Wallet
Hierarchical Deterministic (HD) Wallet
Hot Wallet
Initial Coin Offering (ICO)
Initial Exchange Offering (IEO)
Light Node
Master Private Key
Master Public Key
Master Seed
Merkle Tree
Mining Farm
Mining Pool
Not your keys,...
Orphan block
Paper Wallet
Pieter Wuille
Private key
Proof of Stake (PoS)
Proof of Work (PoW)
Public key
Replace by Fee (RBF)
Roger Ver
Satoshi Nakamoto
Schnorr Signatures
Segregated Witness (Segwit)
Simplified Payment Verification (SPV)
Smart Contract
Soft Fork
Transaction Fees
TransactionId (Txid)
User Activated Soft Fork (UASF)
Wallet Import Format (WIF)
Watch-Only Address
List obviously not complete. Suggestions appreciated.
submitted by PolaT1x to Bitcoin [link] [comments]

A Guide To The BCH Fork on November 15th - Be Informed!

BCH November 15th Forking Guide
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, 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 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:, 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.
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,,, and
If you have further questions about this or just want to discuss the fork in general, we encourage you to join our chat at and join the conversation.
Edit: The fork will occur at roughly 17:40 UTC+0 15.11.2018
Edit 2: Join a livestream at
submitted by cashassociation to btc [link] [comments]

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 :
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 :;9ba4bfca513d6386ee3d313b15bdd4584da7633d
On the other hand, consider Bitcoin Unlimited's OP_DATASIGVERIFY :
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 ). 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:


  1. 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
  2. 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
  3. OP_CHECKDATASIGVERIFY behaves exactly like OP_CHECKDATASIG, except that it fails the entire script immediately if the signature fails to verify
  4. 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.
submitted by moosapor to btc [link] [comments]

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]
  1. 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]
  1. 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]
  1. 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]
  1. 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]
  1. 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]
  1. 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]
  1. 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
  1. 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
submitted by scottsimon36 to nexusearth [link] [comments]

TIL in 2011 a user running a modified mining client intentionally underpaid himself 1 satoshi, which is the only time bitcoin have ever truly been destroyed.

In block 124724 you'll find txid 5d80a29b which has a payout of 49.99999999 BTC at a time when the block reward was 50 BTC. A transaction fee of 0.01 BTC was also forfeited. This bitcoin no longer exists anywhere in the network, as opposed to "burned" coins which technically still exist in a wallet which no one can ever access (ex: 1BitcoinEaterAddressDontSendf59kuE).
On bitcointalk user midnightmagic explains a deeper meaning behind this:
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.
Further reading:
submitted by NewLlama to Bitcoin [link] [comments]

Bitcoin core 0-conf vs using LN.

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:
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.
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:
submitted by Neophyte- to CryptoTechnology [link] [comments]

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:

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.
submitted by hapticpilot to btc [link] [comments]

New Electron Cash coinsplit tool with support for both OP_CDSV and OP_MUL released!

Here (source only, for now):
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:
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.
submitted by markblundeberg to btc [link] [comments]

A reminder of the main advantages of SegWit

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
Third party transaction malleability fixes
Fixing the quadratic scaling of sighash operations bug, making a further bocksize limit increase both safer and more likley
Signing of input values, making Bitcoin easier for hardware devices
Not requiring wallets to download the signature data to check the transaction hash
Introducing script versioning makes upgrades to increase onchain capacity even further far easier
submitted by jonny1000 to Bitcoin [link] [comments]

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:
  1. Apparently Supporting XMR is technically more difficult for wallets and other tools.
  2. 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?
Advantages for BCH:
  1. Supporting BCH with wallets and other tools is technically easier than for XMR.
  2. The tremendous media and social hype around the word "Bitcoin" and BTC also raises the public's consciousness of BCH.
  3. BCH transactions take up less space than XMR, making BCH ledger more scalable.
  4. XMR's reputation as criminal friendly may create political/regulatory pushback.
  5. BCH has already been adopted by more merchants.
  6. More on chain scriptability than XMR.
  7. XMR wallets need the whole ledger. BCH wallets can efficiently update with targeted queries.
  8. The longer history and greater resources behind BCH result in better user interfaces and other related tools than for XMR.
  9. BCH fees are lower than XMR fees. (Although XMR fees are likely to drop with more usage.)
Advantages for XMR:
  1. XMR has far stronger privacy than BCH. BCH coinjoin services are available but much weaker.
  2. XMR privacy is mandatory and consistent, as opposed to voluntary methods like coinjoin services.
  3. 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.)
  4. 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:
  1. Graphene in preparation for greater scaling with sharding and parallelized block validation.
  2. Opcode work for future support of colored coins and other tech.
Relevant XMR improvements in progress:
  1. Efficient range proofs for RingCT to improve scaling with smaller transaction sizes.
  2. 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!
submitted by nevermark to Bitcoincash [link] [comments]

Bitcoin Cash trading is being temporarily suspended on the subreddit until further notice because of a brewing hard fork war on November 15th

You might recall that one time Bitcoin trading was temporarily suspended around August last year because two sides of development (Bitcoin Core, and a bunch of people that disagreed with Bitcoin Core) were at an impasse in regards to scaling, so those that did not agree with Core's vision forked off and created Bitcoin Cash.
Since Cash's creation, it's gone through two planned hard forks to conduct network upgrades like per-block difficulty calculation. This third fork is a bit different, as there are two competing proposals. The first, by the Bitcoin ABC development group, introduces a new opcode that validates messages sent through the blockchain from outside sources. The second, by the Bitcoin "Satoshi's Vision" group (AKA Bitcoin SV), opposes this and instead introduces other opcodes and a block size increase all the way to 128 MB (up from 32 MB). Both proposals are incompatible with the other, and a chain split of some sort will occur.
Of particular concern amongst the Bitcoin Cash community is concerns about the leadership of Bitcoin SV, of which a prominent figurehead (Craig Wright) has pledged to do various things with Bitcoin SV that many argue is exactly against what the Bitcoin & cryptocurrency concepts stand against, like scooping dormant and "lost" coins from "inactive" wallets for redistribution.
As it stands right now, as per (which keeps track of all sorts of things about the Bitcoin and Bitcoin Cash ecosystems), a majority of companies either are prepared to support or explicitly stated support for Bitcoin ABC. But a bunch of mining power right now is backing Bitcoin SV.
While we'd normally let the two warring factions play it out, Coinbase has stated its intention to freeze Bitcoin Cash activity until a point where they deem that a network is healthy enough to resume trading. BitPay (which Valve used as their Bitcoin payment processor before they dropped Bitcoin payments last December) is recommending its users to cut off BCH activity at least two hours before.

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.
submitted by wickedplayer494 to GlobalOffensiveTrade [link] [comments]

BITCOIN, GOLD & SP500 - Alle Assets werden steigen!!! Die ... Hack Bitcoin Wallet - YouTube GramFree EARNING SITE  WITHDRAWAL MONEY  BITCOIN WALLET ... penghasil bitcoin gratis tercepat 100% membayar - YouTube Cartes crypto monnaies Wallet Ballet Bitcoin - YouTube

OpCodes Bitcoin Cash: Fork gelingt offenbar. 16. Mai 2018 // 23 Kommentare. Eine maximale Blocksize von 32 Megabyte, größere Nachrichten im OP_Return-Feld, und eine Handvoll neue opcodes: Bitcoin Cash hat gestern Abend erneut eine Hardfork vollzogen. Negative Nebenwirkungen scheint das Upgrade bisher nicht zu haben. Bitcoin Kurs. International. Deutsch; English; Français; Español; Neueste ... Bitcoin Cash Wallet. Low Fees. Reliable. Secure. Bitcoin Cash is a peer-to-peer electronic cash system. It's a permissionless, decentralized cryptocurrency that requires no trusted third parties and no central bank. Get Wallet. Other Platforms. What is Bitcoin Cash? Bitcoin Cash is not Bitcoin. However, its history is also the history of Bitcoin, because, until August 1, 2017, they were the ... Home of free and open Bitcoin discussion, Bitcoin news, and exclusive AMA (Ask Me Anything) interviews from top Bitcoin industry leaders! This subreddit was created to uphold and honor free speech and the spirit of Bitcoin; learn more about us. Bitcoin is the currency of the Internet. A distributed, worldwide, decentralized digital money ... In Bitcoin Core 0.18.0, bitcoin-qt stores wallet.dat data unencrypted in memory. Upon a crash, it may dump a core file. If a user were to mishandle a core file, an attacker can reconstruct the user's wallet.dat file, including their private keys, via a grep "6231 0500" command. 2 CVE-2018-20587: 2019-02-11: 2019-10-02 Tagged: Bitauth, Bitauth IDE, Bitcoin, bitcoin authentication, bitcoin opcodes, Bitcoin Scripts, bitcoin wallet, Data Signatures, multi-entity authentication, opcode, public key , schnorr. With: 0 Comments. HOW TO: Write Custom Bitcoin Scripts in Bitauth IDE. Bitcoin Script is the language used by Bitcoin to validate transactions. Bitcoin “addresses” are actually locking scripts defined in ...

[index] [23182] [39665] [45046] [24727] [19475] [43898] [49656] [37097] [13678] [17306]

BITCOIN, GOLD & SP500 - Alle Assets werden steigen!!! Die ...

#Bitcoin #Crypto #Blockchain Bitpanda - Hier kaufe ich meine Bitcoin... Ledger (Hardware-Wallet) - Zum sicheren aufbewahren deiner Bit... Les Cartes crypto monnaies Wallet Ballet Bitcoin Vous obtiendrez 5% de réduction sur vos achats en utilisant ce lien: 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 ... Klappe die Videobeschreibung auf um ein paar Infos zu bekommen. Lasst mal ein Like und ein Abo da :D. *****Link***** Link: Please check back for this tool which will be released very soon as our team are working on releasing it very soon. So be on the lookout.Subscribe and hit the B...