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.

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.

The advantages in tagging in the scriptPubKey is that we could tag on a per-output basis, while the cons are that the tagging is only possible with native-segwit and older implementations of bech32 will not understand the tag and will pay to a tagged address as usual, tagging with txversion only allows all or none tags, but it protects P2SH-segwit and all existing wallets.

Tagging an output means that the payer believes this address is one-time-use only, as the payer cannot control the payee’s addresses, tagging should only be used when paying ourselves.

discussion

BIP39 seeds

There was a discussion on BIP39 seeds and the probability of getting a valid BIP39 using randomly chosen words, otherwise known as brute forcing. The probability is about 1:256 for 24 words and 1:16 for 12 words. This is meant to change drastically with SLIP 39, proposed last year, SLIP 39 describes a standard implementation of Shamir’s secret-sharing, which splits a secret into unique parts which can be distributed among participants.

The sharing method requires the existence of a certain amount of parts in order to reconstruct the original secret, just like an N-of-M multisignature scheme, the scheme uses an English wordlist just like the old one along with a Passphrase that allows additional protection of the master secret.

discussion

Schnorr and taproot (etc) upgrade

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

Data piggybacking within the payment_preimage for offline payments in wallets

Piggybacking information within payment_preimage is a suggestion by developer Jose Femenias, it is used to enable sharing a common secret seed between an offline device and an online LN node, both the devices calculate the same per_transaction_secret, the node encrypts the PIN within the payment_preimage and then when the LN wallet receives the payment_preimage it decrypts it showing the PIN, this is provided as proof of payment to the offline device.

An implementation of this scheme would give several popular user experiences a chance to be applied on Lightning. For example, the scheme could work in ordering something from a vending machine, you select a product, scan a QR code and upon payment your wallet shows you a PIN that you type into the vending machine and if the PIN is correct, the product is yours.

Another usage here is what developer ZmnSCPxj called a “pay to pay”, by piggybacking an address for the payer, the payer can use tiny payments to ensure the correctness of an address, thus making a larger payment more secure and preventing spamming to get countless payment addresses that won’t be used.

link to discussion

Visual identification of payee node id

Checking the payee node id in the send dialog is always troublesome, the long hex value can be as confusing as typing a bitcoin address yourself. Just like every other thing in Bitcoin, a visual representation of the payee node id might be helpful.

There were suggestions on the Lightning dev mailing list that called lighting user-facing wallets to add an icon identifier for the id so that we can check if its the correct one, after all we as humans are much better at remembering visual cues that random long hex values, there were counter proposals that suggested using Chernoff Faces, as humans are best fit in recognizing small changes in faces and another that suggested using strings of seperate words, like BIP 39 seeds, that are easier to recognize, or memorize, than random hex values.

link to discussion

Unspecified BOLT Protocol Extensions

Often times nodes need to communicate with each other what their implementation is, looking for specific features that are only in select implementations, the desired feature is a question of node implementation.

A concept of Unspecified protocol extensions has been proposed, they are unspecified as they are not part of the BOLT specifications, each extension must have a set of random 20-byte identifier with type bigger than a certain number. Using the concept of current extension, any extensions that are unidentified by a node will not be recognized, while if the node’s implementation identifies this unspecified extension, both nodes can continue communications knowing that they have the same set of extra features.

Another possible implementation here is having feature bits having 1s for the features your node can recognize and 0 otherwise, this will grow with the number of extra features supported and so the first implementation can be more plausible.

link to proposal

Bitcoin Core 0.17.1 release

Other small news include the release of Bitcoin core 0.17.1 that comes with various minor fixes, performance improvements and better translation!