Feed for tag: segwit
Signatures of Messages Using Bitcoin Private Keys
The processing of signing messages with Bitcoin private keys with P2PKH addresses is a fairly known one but with the introduction of segwit, with its bech32 and P2SH forms, it is unclear how to distinguish these three addresses, a new BIP was proposed by developer Christopher Gilliard intending to set a standard for messages to be signed and verified by different clients.
Annonymous Researcher Demonstrates Antminer S15 Exploit

Recently developer James Hilliard, known for his BIP91 proposal (segwit upgrade), discovered a vulnerability in Bitmain’s Antminer S15 firmware, this was then turned into an exploit by independent security researcher under the twitter handle of @00whiterabbit.

The vulnerability allows a malicious hacker to remotely access the miner with SSH, allowing the attacker to flash a custom firmware without ever being in physical presence with the device. Flashing a firmware could cause an array of problems like decreasing its hash rate by underclocking its processors, shutting it down or even modifying the payout address of the miner, leaving thousands of miners vulnerable to basically anything the attacker desires under certain circumstances.

Summary for December 2018
We’ve been taking a break for the past two months while working on a website upgrade. Since we did not cover news in that time, we decided to make a series of recap articles covering the last two months, starting with news related Bitcoin Core and going through Lightning Network and its related updates.
Schnorr and Taproot Update

An effort to put a solid taproot proposal was done by developer Anthony Towns, the proposal was about segwit v1 with several adjustments to the current segwit version which included :

  • replacing the ECDSA Checksig/CheckMultiSign ops with new Schnorr ops
  • introducing a 33-byte v1 witness addresses that encode a secp256k1 ECC Point P that is spendable either by a direct schnorr signature of a script with the witness data and a taproot/merkle path to the script.
  • Versions for taproot scripts
  • Adding OP_MASK to support script masking via sighash
  • Making invalid opcodes upgradeable to have more flexibility than OP_NOP

read the proposal here

Safer Noinput With Output Tagging
Regarding NOINPUT, there was a proposal that would try to mitigate the risk of accidental double payment, as NOINPUT brings Bitcoin smarter contracts, these contracts can also be abused or used in a dumber way, the proposal here is that a certain bit will be used as a flag to let wallets know that this transaction can be spent with NOINPUT, the tag must be explicitly made by the payer and can have one of two implementations, the first would be a bit in the tx version, the second would be a bit in the scriptPubKey.
BIP 322: Generic Signed Message Format

Message signing and verification is one of the quirks included in Bitcoin clients, although it isn’t used as much, this quirk can help you in different situations like proving the ownership of an address, proving a payment to a real world vendor or like a simple proof of an anonymous identity and avoiding fraud.

Currently this only works with P2PKH addresses (legacy addresses starting with a 1), leaving out a standard way to do it with P2SH or any different type of segwit addresses. Note that there exist some non-standard implementations with limited functionnality.

Bloomfilter Issue With Segwit Addresses

An issue was raised by Andreas Schildbach via bitcoin-dev regarding compatibility issues between segwit and BIP37: Bloom Filtering:

The issue affects only P2WPKH and the special case of transactions without change outputs (such as when emptying a wallet). In this case, neither inputs not outputs contain any data elements that would cause a match for the filter. The public key, which would match, goes to the witness but not to the input.

Read the full thread

An Introduction to Segregated Witness ( Segwit )

If you’ve been around the cryptocurrency space in the last year or so, you had to notice the insane fees on Bitcoin around December and January. Bitcoin’s adoption has been growing along its price and so the amount of transactions done per day has been going up. There was a point where a day’s worth of transaction costs in USD reached 22 Million dollars. For perspective, it currently averages at 200 thousand dollars, that’s about 99% less.

Now while Bitcoin’s price and the cryptocurrency bear market had a toll on that, last year we saw a massive effort by the Bitcoin community to drive up the number of transactions per second the blockchain could handle. To achieve this goal two strategies were proposed, one of them was Bitcoin Core’s effort introducing SegWit, short for Segregated Witness, which was activated by a user activated soft fork (UASF), and the other was Bitcoin Cash’s user activated hard fork . To further explain this we need to touch on simple basic Bitcoin blockchain technical details.