Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Is there a list of software impacted by this CVE, and the versions it is fixed in? (Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a policy matter, not part of the consensus rules and never safe to rely on in any case...) On Thursday 06 May 2021 13:55:53 Antoine Riard via bitcoin-dev wrote: > Hi, > > I'm writing to report a defect in Bitcoin Core bip125 logic with minor > security and operational implications for downstream projects. Though this > defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't > impacted. > > # Problem > > Bip 125 specification describes the following signalling mechanism : > > " > This policy specifies two ways a transaction can signal that it is > replaceable. > > * Explicit signaling: A transaction is considered to have opted in to > allowing replacement of itself if any of its inputs have an nSequence > number less than (0x - 1). > > * Inherited signaling: Transactions that don't explicitly signal > replaceability are replaceable under this policy for as long as any one of > their ancestors signals replaceability and remains unconfirmed. > > One or more transactions currently in the mempool (original transactions) > will be replaced by a new transaction (replacement transaction) that spends > one or more of the same inputs if, > > # The original transactions signal replaceability explicitly or through > inheritance as described in the above Summary section. > " > > An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending an > unconfirmed parent with nSequence <= 0xff_ff_ff_fd should be replaceable as > the child transaction signals "through inheritance". However, the > replacement code as implemented in Core's `PreChecks()` shows that this > behavior isn't enforced and Core's mempool rejects replacement attempts of > an unconfirmed child transaction. > > Branch asserting the behavior is here : > https://github.com/ariard/bitcoin/commits/2021-03-test-rbf > > # Solution > > The defect has not been patched. > > # Downstream Projects Affected > > * LN : State-of-the-art pinning attacks against second-stage HTLCs > transactions were thought to be only possible by exploiting RBF rule 3 on > the necessity of a higher absolute fee [0]. However, this replacement > defect opens the way for an attacker to only pin with an opt-out child > without a higher fee than the honest competing transaction. This lowers the > cost of attack as the malicious pinning transaction only has to be above > mempools'min feerate. This also increases odds of attack success for a > reduced feerate diminishes odds of confirmation ending the pinning. > > A functional test demo illustrating cases is available on this branch: > https://github.com/ariard/bitcoin/commits/2021-05-htlc-preimage-pinnings > > LN nodes operators concerned by this defect might favor anchor outputs > channels, fully mitigating this specific pinning vector. > > * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple > stages of execution with time-sensitive transactions opening the way to > pinning attacks. Those protocols being non-deployed or in early phase, I > would recommend that any in-protocol competing transactions explicitly > signal RBF. > > * Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy, if > the coinjoin transaction is still laying in network mempools, if a > fee-bumping output is spendable by any protocol participant, this > fee-bumping mechanism might be halted by a malicious protocol participant > broadcasting an low-feerate opt-out child. According to bip125, if the > coinjoin parent tx signals replaceability, the child transaction should be > replaceable, whatever its signaling. However Core doesn't apply this > policy. RBF of the coinjoin transaction itself should be used as a > fallback. I'm not aware of any deployed coinjoin using such > "anyone-can-bump" fee-bumping strategy. > > * Simple wallets : RBF engines' behaviors might be altered in ways not > matching the intent of their developers. I invite RBF engines dev to verify > what those components are doing in the light of disclosed information. > > # Discovery > > While reviewing the LN dual-funding flow, I inquired on potential new DoS > vectors introduced by relying on counterparty utxos in this following > analysis [1]. The second DoS issue "RBF opt-out by a Counterparty > Double-Spend" is relying on a malicious chain of transactions where the > parent is signaling RBF opt-in through nSequence<=0xff_ff_ff_ff-1 but the > child, servicing as a pinning transaction, opt-out from the RBF policy. > This pinning trick conception was matching my understanding of Core code > but while reading again the specification, I observed that it was > inconsistent from the inherited signaling mechanism as described in the > bip's "Summary" section. > > After exercising the logic, I did submit the defect to Dave Harding, asking > confirmation of divergence between
Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Hi Antoine,
Thanks for bringing this up.
It seems spacechains[0] are impacted by this. Simply explained, the idea is
to allow for fee-bidding Blind Merged Mining[1] by creating one transaction
for each block, to which anyone can attach a block hash. The preferred
mechanism utilizes sighash_anyprevout and is not affected, but there is
also a practical variant that could be used without requiring the
anyprevout soft fork, which unfortunately does seem to be impacted. Here's
a brief description:
TX0:
input 0
output 1a*
output 1b
TX1:
input 1a*
output 2a**
output 2b
TX2:
input 2a**
output 3a***
output 3b
Etc.
Every TX has two outputs, one of which ("a") is used as the input for the
next TX (these are pre-signed and act as a covenant), resulting in a
continuous chain of transactions. The other output ("b") can be spent by
anyone, and is meant to CPFP the parent TX and, importantly, be RBF
replaceable by anyone. This allows whoever pays the highest CPFP fee to
"win the RBF auction" and attach their TX to the output, containing the
winning spacechain block hash.
With inherited signalling, this works because each pre-signed TX is RBF
enabled, so each CPFP transaction inherits RBF as well. But if inherited
signalling does not function, the first person who makes a CPFP transaction
can simply disable RBF and win the auction, thus breaking the intended
fee-bidding mechanism.
You can also find a diagram in this spacechains presentation (timestamped
link): https://youtu.be/N2ow4Q34Jeg?t=2555
As it stands, this bug gets in the way of being able to deploy spacechains.
-- Ruben Somsen
[0]
https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302
[1] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5
On Sun, May 9, 2021 at 10:41 AM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Antoine,
>
>
> Thank you for the disclosure.
>
>
>
> > * Onchain DLC/Coinswap/Vault : Those contract protocols have also
> multiple stages of execution with time-sensitive transactions opening the
> way to pinning attacks. Those protocols being non-deployed or in early
> phase, I would recommend that any in-protocol competing transactions
> explicitly signal RBF.
>
>
> For what it's worth, Revault isn't vulnerable as all transactions signal
> RBF and there is no way to sneak a non-signaling competing transaction (as
> long as the CSV isn't matured yet).
>
>
>
> Thanks,
>
> Antoine (the other one)___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal for an Informational BIP
Hi Chris, I apologise if I did not make it clear enough, but the 24 seed words used to make the quantum passphrase are separate, newly generated 24 seed words, and not the same as those for the main wallet. With both layers (seed words + quantum passphrase) the security provided is (2048^23)^(2048^23). ie. 2048 to the power of 23, to the power of 2048 to the power of 23 possible combinations of words. The BIP39 passphrase is designed to prevent catastrophic loss of funds in the case of accidental seed word exposure. If both, seed words and quantum passphrase, are stored on two separate metal backup storage plates, in two separate locations, then the accidental disclosure of either one provides 2048^23 (or 10^76) possible combinations of words to decrypt. ie. The quantum passphrase provides the same degree of security, as the original 24 seed words. I hope this helps. Best regards, Chris On Tue, 11 May 2021, 17:54 Chris D'Costa, wrote: > "well established security of the existing BIP39 standard" > > You are basing your entire proposal on this basic misunderstanding. > > There is no inherent (or "existing") security in BIP39. All it does is > provide a standardised and convenient way to record, and recover a > private key from a readable seed phrase. In fact there are many language > versions of BIP39 dictionary. But really the worst part of the idea from a > security perspective is that it reveals the seed phrase. Even a simple > password to encrypt (whilst possibly weak) would still never so this! > > C > > > On Tue, 11 May 2021 at 10:48, BitPLATES (Chris) < > bitpla...@marketnetworks.co.uk> wrote: > >> Hi Chris, >> >> Thank you for your thoughts. >> >> Unfortunately, your analysis is incorrect. >> >> This is a non-destructive adaptation of the BIP39 standard, and is >> certainly not "rolling your own security". >> >> The 'quantum' passphrase is relying on the well established security of >> the existing BIP39 standard. >> >> There are 2048 possible words that can be chosen from the BIP39 word >> list. Therefore, to derive a seed from a string of 24 BIP39 words, is >> exactly the same as deriving a seed from the full 24 words: >> >> 2048 to the power of 23 combinations of security (not the power of 24 >> because of the checksum), or 10 to the power of 76 combinations. >> >> If you created your own combinations of words to make up a passphrase, >> this same degree of security would require 15 random words from the English >> dictionary (assuming 100,000 English words): >> >> 100,000 to the power of 15 = 10 to the power of 75 combinations. >> >> The other problem with this, is that you could not plausibly deny that it >> was a passphrase, whereas, using a 'quantum' passphrase allows you to >> backup your passphrase disguised as a 24 seed mnemonic. >> >> I hope this alleviates your concerns. >> >> All the best, >> >> Chris >> >> >> On Tue, 11 May 2021, 09:12 Chris D'Costa, wrote: >> >>> I think the biggest problem you have with this proposal is "rolling your >>> own security". >>> >>> Are you aware that the dictionary is designed such that the first four >>> letters are unique to each word? Taking those four letters and >>> concatenating them to a string basically means that I can derive your seed >>> from your supposedly secure "quantum" passphrase. It does not add to the >>> security - if anything it makes it worse. It would be orders of magnitude >>> worse than using a random password and encryption as most wallets have been >>> using for years. >>> >>> C >>> >>> On Sat, 8 May 2021 at 17:21, BitPLATES® (Chris) via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> Hi, I'd like to submit an idea for review, as a potential informational BIP (Bitcoin Improvement Proposal), describing an optional method of producing a BIP39 passphrase, using only BIP39 'mnemonic' seed words. The idea specifically refers to a method of introducing two-factor authentication, to protect a Bitcoin wallet using only 24 seed words, and therefore, providing plausible deniability about the existence of this separate 2nd layer passphrase. I've suggested the name 'quantum' passphrase to be used casually as a unique identifier. The data stored within a 'quantum' passphrase, is simultaneously the minimum required data for reproducing a BIP39-compatible 24-word seed mnemonic... hence, the name 'quantum' seems fitting, to reflect the multiple simultaneous states of data. Abstract... This improvement proposal describes the use of twenty four, newly generated BIP39 seed words, to produce a '25th-word' BIP39-compatible 'quantum' passphrase. Two-factor authentication (2FA) or (2 of 2 multi-signature) can be implemented with a two-wallet setup: The 1st Bitcoin wallet is protected by the seed words of the 2nd Bitcoin wallet; inversely, the 2nd Bitcoin wallet is
Re: [bitcoin-dev] Prediction Markets and Bitcoin
Good morning ZmnSCPxj, This will be a long email because I want to cover all the things and difficult to express them in few sentences or respond to the tweets about use of futures markets in Bitcoin. TL;DR: Prediction markets or futures markets can be helpful in collecting more information and hedging however, if used incorrectly can become a reason for failure of Bitcoin. === > Of course development must be free to do what is best technically, and to >experiment and see what other techniques are possible or workable. Thus the >market must follow development. Agree. > Of course the people ultimately funding the development must impose what >direction that development goes to, after all, it is their money that is being >modified. Thus development must follow the market. Disagree. 1.A position in a futures market about possible outcomes of an event is not equivalent to funding Bitcoin development. 2.People or organizations funding Bitcoin developers or projects can always have some opinion, influence and disagreements. They can never impose or force something at least in Bitcoin protocol. > what is unclear is what the market wants, thus I think prediction markets are > something that are needed in order for the negotiation Partially agree. Yes, its not clear what the market wants and sometimes its unclear even after expiry of futures contract because two people can look at the same data and share different analysis. Prediction markets are not needed for negotiation but can be helpful sometimes. === 3 things I mentioned in TL;DR: Hedging, Collecting information and Incorrect usage 1.Hedging: Futures market can be useful in hedging few things in Bitcoin. Jack Mallers had shared the idea of using futures markets for 'fees' in Lightning Conference: https://www.youtube.com/watch?v=rBCG0btUlTw Summary of the presentation(Hedging the chain): Derivatives contracts are used to hedge financial exposure. Projects and businesses that use bitcoin transactions regularly prefer paying less transaction fees. Miners revenue increases if transaction fees goes up and subsidy is reduced after every 210,000 blocks so miners prefer high transaction fees or more fees per block. Examples: A)Zap expects $1000/month on-chain operating costs. Longs(1x) on-chain fee futures. If bitcoin transaction fees for the month costs more than $1000, the loss will be covered with profits from long position. If long position is in loss because fees are low, it will be covered by paying less than $1000 for the month in transaction fees. Miner expects $1000/month on-chain fee profits. Shorts(1x) on-chain fee futures. If short position is in loss because fees go up, loss will be covered with more profits from mining. If profits are less from mining because fees was low, loss will be covered with profits in short position, B)Hashrate Derivatives: https://onthebrink-podcast.com/tim-kelly-bitooda/ C)Consider there is a futures contract for Taproot soft fork. Alice has done enough research and thinks Taproot will be activated. She opens a long position. Bob thinks miners signaling will not reach the required threshold, so Taproot will not be activated with MASF. Bob opens a short position. Carol is working on a project that will work better with taproot activated. She is not interested in speculating but wants to hedge the financial exposure. Carol expects her project will receive $1 funding and make $1000 profits per month. She opens a short position (1x) which will cover the loss incase taproot is not activated. If taproot is not activated, UASF can take another year which will delay her funding and profits but she can cover this loss with the profits from short position. This futures contract will expire on 2021-08-11 00:00 UTC and settlement is based on multiple oracles that broadcast results for `getblockchaininfo` regularly for their nodes. Start date can be before or after signaling. Trade-offs: If the futures contract starts before signaling, miners are likely to follow the market (not necessary). If the futures contract starts after a week of signaling, traders can use this information while opening a position. In this example, futures contract starts from 2021-05-01 00:00 UTC. Similarly if we improve privacy in Bitcoin with a soft fork that includes confidential transactions, Chainalysis can use such futures contract to open a long position because it affects their business. If CT-SF is activated, they can cover some loss with the profits from long position. 2.Collecting more information: a - Bitcoin Dev Mailing List b - Different PRs: GitHub repository for Bitcoin Core and other implementations c - IRC channels d - Bitcoin Stackexchange (If not sure about some technical things involved in a soft fork) e - Reddit posts f - Twitter (Not the best
Re: [bitcoin-dev] Proposal for an Informational BIP
Hi Chris, Thank you for your thoughts. Unfortunately, your analysis is incorrect. This is a non-destructive adaptation of the BIP39 standard, and is certainly not "rolling your own security". The 'quantum' passphrase is relying on the well established security of the existing BIP39 standard. There are 2048 possible words that can be chosen from the BIP39 word list. Therefore, to derive a seed from a string of 24 BIP39 words, is exactly the same as deriving a seed from the full 24 words: 2048 to the power of 23 combinations of security (not the power of 24 because of the checksum), or 10 to the power of 76 combinations. If you created your own combinations of words to make up a passphrase, this same degree of security would require 15 random words from the English dictionary (assuming 100,000 English words): 100,000 to the power of 15 = 10 to the power of 75 combinations. The other problem with this, is that you could not plausibly deny that it was a passphrase, whereas, using a 'quantum' passphrase allows you to backup your passphrase disguised as a 24 seed mnemonic. I hope this alleviates your concerns. All the best, Chris On Tue, 11 May 2021, 09:12 Chris D'Costa, wrote: > I think the biggest problem you have with this proposal is "rolling your > own security". > > Are you aware that the dictionary is designed such that the first four > letters are unique to each word? Taking those four letters and > concatenating them to a string basically means that I can derive your seed > from your supposedly secure "quantum" passphrase. It does not add to the > security - if anything it makes it worse. It would be orders of magnitude > worse than using a random password and encryption as most wallets have been > using for years. > > C > > On Sat, 8 May 2021 at 17:21, BitPLATES® (Chris) via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi, >> >> I'd like to submit an idea for review, as a potential informational BIP >> (Bitcoin Improvement Proposal), describing an optional method of producing >> a BIP39 passphrase, using only BIP39 'mnemonic' seed words. >> >> The idea specifically refers to a method of introducing two-factor >> authentication, to protect a Bitcoin wallet using only 24 seed words, and >> therefore, providing plausible deniability about the existence of this >> separate 2nd layer passphrase. >> >> I've suggested the name 'quantum' passphrase to be used casually as a >> unique identifier. >> >> The data stored within a 'quantum' passphrase, is simultaneously the >> minimum required data for reproducing a BIP39-compatible 24-word seed >> mnemonic... hence, the name 'quantum' seems fitting, to reflect the >> multiple simultaneous states of data. >> >> Abstract... >> >> This improvement proposal describes the use of twenty four, newly >> generated BIP39 seed words, to produce a '25th-word' BIP39-compatible >> 'quantum' passphrase. >> >> Two-factor authentication (2FA) or (2 of 2 multi-signature) can be >> implemented with a two-wallet setup: >> >> The 1st Bitcoin wallet is protected by the seed words of the 2nd Bitcoin >> wallet; inversely, the 2nd Bitcoin wallet is protected by the seed words of >> the 1st Bitcoin wallet. >> >> The 'quantum' passphrase offers an exponential increase in the level of >> protection, as that offered by the original BIP39 mnemonic seed words >> (≈2048^23 possible combinations). >> >> ie. A Bitcoin wallet with a 2nd layer 'quantum'passphrase is protected by >> 2048^23 to the power of 2048^23 possible combinations. >> >> With existing computer capabilities, this level of protection is far >> greater than required; however, this does provide a sufficient level of >> protection for each separate layer of a two-factor Bitcoin wallet, should >> any one layer be accidentally exposed. >> >> This method of passphrase generation, consists of two parts: >> >> 1st - generating the BIP39 mnemonic seed words, using a BIP39-compatible >> hardware wallet. >> >> 2nd - Converting these seed words into the 'quantum' passphrase, >> following four simple rules, which most importantly, do not destroy the >> integrity of the initial data. >> >> Motivation... >> >> The well established practice of preserving up to 24 seed words for the >> purpose of reproduction of a Bitcoin wallet, suffers from a major flaw... >> Exposure of these mnemonic seed words can cause catastrophic loss of funds >> without adequate multi-factor protection. >> >> Whilst it is recognised that a number of multi-factor solutions are >> available (including the standard BIP39 passphrase, and hardware wallet >> multi-signature functionality), this proposal aims to provide an extremely >> safe and secure 'low-tech' option, that requires minimal (non-destructive) >> adjustments to the seed words. >> >> Furthermore, the 'quantum' passphrase offers a number advantages over the >> existing methods of multi-factor protection: >> >> Firstly, this method of creating a passphrase leaves no evidence of
