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.
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.
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.
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 newSchnorr
ops - introducing a
33-byte
v1 witness addresses that encode asecp256k1
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
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.
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.
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.
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!
Support us and the authors of this article by donating to the following address:
3ErScNs3DuG1zYThFVkbTLxcce8ycQsGhG
Comments powered by Talkyard.