Feed for category: blockchain
OP_DIFFICULTY To Enable Difficulty Hedges Without an Oracle and 3rd Party

Every financial market has bets, some are bets on the availability of a certain product, the price of a certain product at a certain point in time and on productivity and all markets depend on supply and demand, in metal markets the supply is the amount of metal that was produced this year, in Bitcoin that amount is fixed so people can’t bet on it. What you can bet on is how much it costs to mine Bitcoin at a certain time, specifically the difficulty, as the difficulty rises miners need more powerful, and probably more expensive, machines to be able to compete.

For anyone wanting to enter the mining business, this is the biggest risk there is, and while commodity markets offer futures and options to hedge risks, currently Bitcoin doesn’t employ this.

That’s why developer Tamas Blummer suggested the OP_DIFFICULTY, an opcode to enable hedges without any 3rd party interference, settled on the blockchain.

Improving SPV Security With POW Fraud Proofs

Bitcoin full nodes require increasing computer resources that are not available to most of the public, therefore most users tend to use SPV. Simplified Payment Verification is a way for users to check the validity of a block without downloading the whole blockchain, only needing a copy of the block headers of the longest chain.

This schema makes SPV clients vulnerable to forks as it is secure under the assumption that the longest chain is valid and as attacks like Segwit2x have shown and this is not always a safe assumption. A new schema has been proposed on the Bitcoin-dev mailing list that allows invalid blocks to be rejected as long as there are enough honest miners to create a block within a reasonable time frame. The new schema doesn’t fully protect clients against dishonest miners but is an improvement over the current SPV.

Self Balancing Between Excessively Low/High Fees and Block Size
A new BIP being discussed on the Bitcoin-dev mailing list is aiming at making variable Bitcoin block size depending on the fee the sender is willing to pay, the BIP is aiming at making the block space small, decrease the impact of spam transactions, balancing fees with smaller fees increasing in a higher percentage than higher fees, allow larger block size if the sender is willing to pay for it, allow wallets to display the amount, and price, of free block space left and allow senders to have more control on their fee/priority structure.
Introducing Liquid Core

Blockstream has just introduced Liquid Core, a multiplatform desktop wallet for transacting Liquid Bitcoin.

Users can deposit to supporting exchanges and withdraw as well as engage in peer-to-peer transactions. In addition, transactions are significantly faster (settled in two minutes) and users enjoy a default confidential transaction setting that hides sensitive transaction details such as transaction asset and amount from third parties.

Anyone familiar with wallets can use the Liquid Core wallet although Bitcoin Core users will find it much easier to navigate. Requirements and instructions on how to use the wallet are available on the website. See more details to get started.

BTCPay Server Payment Request: Invoice Clients and Get Paid in BTC by Sharing a Simple Link

The team at BTC Pay Server published an article introducing their Payment Requests feature.

It allows you to get paid in cryptocurrency just by sharing a simple URL using a new type of time-sensitive inoice page built into BTCPay.

BTCPay Server is an open-source cross platform, self-hosted bitcoin server compatible with Bitpay API.

Blockstream Explorer Updates
Blockstream published a few updates to its block explorer that was launched last year 2018. The most obvious of the changes is the enabling of address search with unlimited transactions. Although it takes more disk space, that has led to increased search speed for the explorer. Secondly, disabling Java Script has also been made possible to allow for more browsing privacy as Java Script can be used to remove anonymity of users especially those using Tor, to improve user experience significantly. Thirdly, an API endpoint and a web form have been added to enable transaction broadcasting, a feature that developers or users who may want to easily broadcast transactions to the Bitcoin Network may find useful.
Simple Proof of Reserves Transactions

Proof-of-reserve transactions are transactions provided by a certain custodian to prove ownership for an amount of funds. For example, lets say an Exchange currently holds 30 thousand Bitcoins on behalf of its users, if anything happens to the exchange, say a hack, the exchange might need to prove to its customers that their Bitcoin is in safe hands, currently any company that wants to perform a proof-of-reserve must do it in its own way and accordingly, their users have to understand the construction to be able to verify it, this makes the process not very common among custodian companies as it’s both tiresome and would require educating their users on technical terms.

A new BIP was proposed as a way to formalize a standard format for constructing these proofs, making it easier for custodians and users with existing wallet infrastructures to understand these proofs. Proofs are formatted as a regular Bitcoin transaction with small differences. This transaction must be unspendable as its sole purpose is to demonstrate the availability of the funds, not spending them. The proof must be linked to the issuer, preventing custodians from just copying other custodians’ proofs.

Proof of Stake Bitcoin Sidechains
Proof of stake is another consensus protocol that has been used on multiple block chains for quite some time now, there was a proposal on the Bitcoin-dev mailing list to attach proof of stake sidechains to the original Bitcoin blockchain. This allows for the development of decentralized networks which aim to manage reserves of Bitcoin, using custom application code and smart contracts that use Bitcoin as the native currency.