Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
I found the original explanation a bit confusing. As I understand it, the attack starts by double-spending the timeout HTLC transaction of the victim with a pre-image revealing HTLC transaction. This itself is not an attack: the victim can then use the pre-image to receive its incoming HTLC safely, because its timeout hasn't expired yet. The trick is now that the attacker double-spends their own transaction before it hits the chain (the third transaction only double-spends some attacker controlled input used also by the pre-image HTLC transaction). In ideal condition, the pre-image transaction is never seen by the victim and the victim still doesn't know the pre-image. The attacker may only attack the mempool of the mining nodes. The victim may not even know that their transaction was replaced and are only confused why it didn't get mined. On Fri, 20 Oct 2023 at 12:47, Peter Todd via bitcoin-dev wrote: > > On Tue, Oct 17, 2023 at 02:11:20AM +0100, Antoine Riard wrote: > > > I think if you want people to understand this exploit, you need to > > explain in more detail how we have a situation where two different parties > > can spend the same HTLC txout, without the first party having the right to > > spend it via their knowledge of the HTLC-preimage. > > > > If I'm correctly understanding your question, you're asking why we have a > > situation where the spend of a HTLC output can be in competition between 2 > > channel counterparties. > > No, you are not correctly understanding it. > > It's obvious that an HTLC output can be in competition between 2 different > parties. Obviously, the HTLC-preimage doesn't expire. The problem is you > haven't explained why the party with the HTLC pre-image should not *remain* > the > party with the *right* to spend that output, even after the timeout branch > becomes another possible way to spend it. > > > LN commitment transactions have offered HTLC outputs where a counterparty > > Alice is pledging to her other counterparty Caroll the HTLC amount in > > exchange of a preimage (and Caroll signature). > > > > After the expiration of the HTLC timelock, if the HTLC has not been claimed > > on-chain by Caroll, Alice can claim it back with her signature (and the > > pre-exchanged Caroll signature). > > > > The exploit works actually in Caroll leveraging her HTLC-preimage > > transaction as a replace-by-fee of Alice's HTLC-timeout _after_ the > > expiration of the timelock, the HTLC-preimage transaction staying consensus > > valid. > > That's precisely my point re: you not properly explaining the problem. If > Caroll has the HTLC-preimage, she has the right to spend it. You need to > explain why her right to spend that HTLC-preimage output should expire. > > If anything, the way you've explained it sounds like Bob has stolen the output > from Caroll by virtue of the fact that Caroll wasn't able to spend the > HTLC-preimage output in time. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > 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] Signature and Script Independent Hierarchy for Deterministic Wallets.
Hello Robert, you wrote: > It is not fair nor accurate to say that currently, in order to recover, wallets need "just the seed words". They also need all public keys, and derivation paths. No a BIP39/BIP44 wallet can recover all BIP44 accounts using just the seed words. Read the section account recovery closely to see how it's done. No public keys or derivation paths needed, as the derivation path can just be enumerated and for single signature wallets you don't need external public keys. Similarly a BIP39/BIP44/BIP49/BIP84 can recover all these accounts using just the seed words and for example the Trezor Suite does this. Most hardware wallets currently rely on this feature, as they don't store any additional information like output descriptors (which would be possible, but would make regular backups necessary). Of course, autodiscover doesn't work for multisig wallets, unless you would store some output descriptor in an OP_RETURN on the blockchain. It's okay to make a new standard that requires regular backups, but you should at least keep in mind that this complicates some use cases. Jochen On Tue, 16 Mar 2021 at 13:19, Robert Spigler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > No, wallets don't and shouldn't have to check all script types on > recovery. Descriptor Wallets solve all of this. > > To back up a multisignature wallet, each cosigner stores their xprv (how > you do this; BIP39, WIF, etc, is out of scope). and the wallet descriptor. > This is done, for example, in Yeti. To recover, simply combine `M` private > keys, and check the script designated in 1 of the descriptor copies. > > For single signature wallets, it is the same, except only one signature is > needed. Store xprv and descriptor. > > It is not fair nor accurate to say that currently, in order to recover, > wallets need "just the seed words". They also need all public keys, and > derivation paths. > > Descriptors (and this BIP), is a much cleaner way to handle wallet > creation and backup, by separating the two layers (keys and scripts) and > getting rid of redundant information. > > > Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F > > > > ‐‐‐ Original Message ‐‐‐ > On Sunday, March 14, 2021 11:13 AM, SomberNight < > somber.ni...@protonmail.com> wrote: > > > See some replies inline. (quoted text from BIP draft) > > > > > Date: Sun, 14 Mar 2021 01:51:15 + > > > From: Robert Spigler robertspig...@protonmail.ch > > > Subject: [bitcoin-dev] Signature and Script Independent Hierarchy for > Deterministic Wallets. > > > > > There are many issues with the current standards. As background, BIP > 44/49/84 specifies: > > > `m / purpose' / coin_type' / account' / change / address_index` > > > where the BIP43 `purpose'` path is separate for each script (P2PKH, > P2WPKH-in-P2SH, and P2WPKH respectively). However, these per-script > derivations are made redundant with descriptors > > > > > We should not be mixing keys and scripts in the same layer. The wallet > should create extended private/public keys independent of the script or > signature type > > > > You say that keys and scripts should not be mixed in the same layer, and > imply that this was solely done due to these standards predating output > script descriptors. Even if this was the case, it is not the only reason > for doing it. BIP44/49/84 mixing scripts and keys in the same layer makes > recovery from seed/mnemonic much easier. > > Note the significant overlap between the authors of BIP39 and BIP44. I > am fairly certain BIP44 was designed with recovering from a BIP39 seed (and > no additional information backed up) in mind. Note the "Account discovery" > section of BIP44. > > (Electrum seeds go even further, as such seeds contain a version number > that encodes both the script type and the key derivation path to use.) > > > > > We define the following 5 levels in the BIP32 path: > > > `m / purpose' / coin_type' / account' / change / address_index` > > > > > [Account] > > > It is crucial that this level is increased for each new wallet joined > or private/public keys created; for both privacy and cryptographic purposes. > > > For example, in multisignature wallets, before sending a new key > record to a coordinator, the wallet must increment the `account'` level. > Before creating it's own single signature wallet, the `account'` level must > again be incremented. > > > > Imagine a user who has a BIP39 (or similar) seed. Even today, recovering > most non-singlesig scripts from that is obviously infeasible. However, all > singlesig scripts at least can be discovered if the keys are using the > suggested derivation paths. > > By trying to create a standard that mixes discoverable and > non-discoverable scripts in the same derivation scheme and incrementing a > single index, you are turning all scripts into being non-discoverable. > > Note that even if a user only used singlesig scripts and followed this > propos
Re: [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
On Tue, 14 Jul 2020 at 16:42, ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning Mr. Lee, > > > Sorry. Re-sending with correction to CC bitcoin-dev > > > > I am sorry if this was already brought up in previous threads. If I know > > lightning network correctly then HTLC is used to enforce settlements on > > blockchain if there is a dispute. Could a person lose money if their HTLC > > does not get confirmed in the timeframe or if an older HTLC gets > > confirmed first? I see different ways this could happen. > > > > One, if the blockchain is very saturated with other transactions. The > > reason we need lightning network is why it might have troubles with > > settlements? > > This could happen, but the entire exercise is to move transactions off the > blockchain, precisely to lower this risk. > > Otherwise, transfers onchain will take a long time. > In practice, a long time to settle a payment will invalidate many > real-world economic exchanges anyway (consider paying for food at a > restaurant --- if your payments take days to settle, the food has gotten > stale before the restaurant receives payment and releases your food). > Thus, if an onchain transfer takes a long time to settle, there is already > risk of economic loss present. > > By moving activity offchain, we reduce pressure onchain and improve > settlement speeds on both offchain and onchain, reducing risk of economic > loss due to delay. > > > > Two, competition from a different conflicting HTLC. A newer > > HTLC might not get confirmed before an older HTL. > > I cannot make sense of this. > > You cannot create conflicting HTLCs. > Correct. Removing or Creating an HTLC is something that both channel partners need to agree on. They may create multiple pending HTLCs as long as there are enough funds, but creating conflicting HTLCs is not possible. > > > > I found out about a recent attack technique that sounds like it might be > > similar called "flood and loot". > > Roughly, my understanding of Flood and Loot is to make a lot of > uneconomically tiny HTLCs going through a target victim forwarding node. > You make circular routes going from your own node back to yourself. > Then you refuse to actually claim the HTLCs sent back to yourself. > No, the way I understand it is that an attacker, say Malleroy, routes a lot of medium sized HTLC payments from his node to his node via a victim node, say Alice's, and possibly other nodes. Then Malleroy *accepts* the payments by publishing the hash on the receiving end, so he gets all the sent funds on his receiving channel. Malleroy's receiving node behaves completely honestly, and nobody can prove that it belongs to the attacker. Finally when Alice claims her HTLC by presenting the hash, Malleroy just ignores the claim. Now Alice, the victim, is forced to close the channel to prevent the HTLC to timeout. If Malleroy does it with multiple victims at exactly the same time, they will all compete with each other. The victims cannot increase the fee for the HTLC claiming transaction, because they are the ones who force-closed the channel. CPFP doesn't work, because their ultimate output is CLTV'd. As soon as the HTLC timeouts Malleroy can claim the still pending HTLCs using an RBF transaction. So it is Alice who has to force close, which puts her at a big disadvantage. Malleroy will have to pay the lightning fees, but they are negligible. The fee for the on-chain force-close transaction (with the HTLC outputs) is paid by whoever opened the channel. AFAIK the fee for the HTLC resolving transactions is paid by whoever claims the HTLC. In this scenario it is paid from Alice's money. If Malleroy opened the channel, he risks losing some funds to on-chain fees. On the other hand the one who pays the fee controls the fee. He could negotiate a very low fee (say a cent per HTLC), when the network is idle and then wait for a natural congestion before starting the attack, giving him a low risk with high success probability. Every HTLC he can claim after timeout is profit. Regards, Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format
On 21.08.2017 20:12, Greg Sanders via bitcoin-dev wrote: > To fix this I consulted with andytoshi and got something we think works > for both cases: > > 1) When a signing device receives a partially signed transaction, all > inputs must come with a ownership proof: > - For the input at address A, a signature over H(A || x) using the key > for A. 'x' is some private fixed key that only the signing device > knows(most likely some privkey along some unique bip32 path). > - For each input ownership proof, the HW wallet validates each signature > over the hashed message, then attempts to "decode" the hash by applying > its own 'x'. If the hash doesn't match, it cannot be its own input. > - Sign for every input that is yours Interesting, basically a proof of non-ownership :), a proof that the hardware wallet doesn't own the address. But shouldn't x be public, so that the device can verify the signature? Can you expand on this, what is exactly signed with which key and how is it checked? One also has to make sure that it's not possible to reuse signatures as ownership proof that were made for a different purpose. Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
On 24.08.2016 16:18, Jonas Schnelli via bitcoin-dev wrote: > > Another thing that I think could be a BIP misdesign: > > BIP44 Gap Limits > From the BIP: > > -- > "Address gap limit is currently set to 20. If the software hits 20 > unused addresses in a row, it expects there are no used addresses beyond > this point and stops searching the address chain." > -- > > * Does that mean, we do a transaction rescan back to the genesis block > for every 20 addresses? As I understand it, you can scan sequentially starting with the genesis block (or with a block at around the time when BIP44 was written). Then if you find a new transaction, which requires to generate new addresses, you generate them and scan further from that point on. This way you can scan in a single pass if the scanning process calls you back when it finds a transaction and allows you to change the set of addresses on the fly. Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Hardware Wallet Standard
Hello Jonas,
thanks for your efforts of writing the draft for the standard.
First, this only describes detached signing. A wallet also needs to
connect with a hardware wallet at some time to learn the xpubs
controlled by the hardware. Do you plan to have this in a separate
standard or should this also be included here? Basically one needs one
operation: get xpub for an HD path.
From a first read over the specification I found the following points
missing, that a fully checking hardware wallet needs to know:
- the amount spent by each input (necessary for segwit).
- the full serialized input transactions (without witness informations)
to prove that the amount really matches (this is not necessary for segwit)
- the position of the change output and its HD Path (to verify that it
really is a change output).
- For multisig change addresses, there are more extensive checks
necessary: All inputs must be multisig addresses signed with public
keys derived from the same set of xpubs as the change address and use
the same "m of n" scheme. So for multisig inputs and multisig change
address the standard should allow to give the parent xpubs of the other
public keys and their derivation paths.
It is also a bit ambiguous what the "inputscript" is especially for p2sh
transactions. Is this always the scriptPubKey of the transaction output
that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
there are three scripts
witness: 0 <1 2 CHECKMULTISIG>
scriptSig:<0 <32-byte-hash>>
(0x220020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
(0xA914{20-byte-hash}87)
(quoted from BIP-141).
In principle one could put witness and scriptSig (with "OP_FALSE" in
places of the signatures) in the raw transaction and make inputscript
always the scriptPubKey of the corresponding output. Then one also
doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
nested in bip16 p2sh" transactions.
Regards,
Jochen
signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: derived mnemonics
Jonas Schnelli via bitcoin-dev schrieb am Di., 26. Juli 2016 um 22:10 Uhr: > Side-note: Bip39 does still use PBKDF2 with 2048 iterations which I > personally consider "not enough" to protect a serious amount of funds. > > But what are the alternatives? Put an expensive processor and a decent amount of memory in every hardware wallet to support scrypt? Use a million iterations and just wait 10 minutes after entering you passphrase? Or compute the secret key on your online computer instead? Also, how many iterations are secure? A million? Then just add two random lower-case letters to the end of your passphrase and you have a better protection with 2048 iterations. If you want to be able to use your passphrase with cheap hardware and be protected against a high-end computer with multiple GPUs that is almost a mllion times faster, then you have to choose a good passphrase. Or just make sure nobody steals your seed; it is not a brainwallet that is only protected by the passphrase after all. Regards, Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
Hello Daniel, Am 14.06.2016 um 17:41 schrieb Daniel Weigl via bitcoin-dev: > Hi List, > > Following up to the discussion last month ( > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012695.html > ), ive prepared a proposal for a BIP here: > > > https://github.com/DanielWeigl/bips/blob/master/bip-p2sh-accounts.mediawiki > > > Any comments on it? Does anyone working on a BIP44 compliant wallet implement > something different? > If there are no objection, id also like to request a number for it. thank you for going forward with this. Should we keep the discussion on the list, or should we make it on github? I think we should already consider not only P2WPKH over P2SH addresses but also "native" P2WPKH addresses. Instead of having one BIP for these two kinds of segwit addresses and forcing the user to have several different accounts for each BIP, the idea would be that every fully BIP?? compatible wallet must support both of them. Since P2WPKH is simpler than P2WPKH over P2SH, this is IMHO reasonable to require. I would go with the suggestion from Aaron Voisine to use different chain id's to distinguish between different address types. E.g., 0,1 for P2WPKH over P2SH and 2,3 for native P2WPKH. I see no reason why a wallet would want to use P2WPKH over P2SH for change addresses instead of native P2WPKH, though. Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
Am 14.05.2016 um 10:16 schrieb Jonas Schnelli via bitcoin-dev: > > Importing a bip32 wallet (bip44 or not) is still an expert job IMO. > Also importing can lead to bad security practice (especially without a > sweep). One important use case is importing xpubs for watch-only accounts. This is necessary for hardware wallets and there are other valid use cases for this. > > Users will send around xpriv or import an seed over a compromised > computer to a cold storage, etc. > > I don't think users want to import private keys. > They probably want to import the transaction history and send all funds > covered by that seed to a new wallet. > Yes, in general it is not a good idea to import private keys and many wallets don't even have an option to give out the xprv (except indirectly via the backup mechanism). But even when sweeping a bip-44+segwit wallet you need to know where the segwit addresses are. Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
Am 13.05.2016 um 15:16 schrieb Daniel Weigl via bitcoin-dev: > > With SegWit approaching it would make sense to define a common derivation > scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) > receiving addresses. > I was thinking about starting a BIP for it, but I wanted to get some feedback > from other wallets devs first. > The discussion so far shows that starting a new BIP is a very good idea. Otherwise everyone would do it slightly different. With P2(W)SH you mean P2WPKH embedded in P2SH, right? P2WSH is completely different and used for example for multisig. > In my opinion there are two(?) different options: To summarize, option 1 means one account that supports both non-segwit and segwit addresses. With option 2 you have one p2pkh-only account and one segwit-only account, which are completely separated. I personally would vote for option 1. Scanning twice the addresses can be avoided with Aaron's trick. The second disadvantage remains: > -) If you have the same xPub/xPriv key in different wallets, you need > to be sure both take care for the different address types A non-segwit wallet would ignore all segwit outputs, which means that the balance it shows is smaller (and it doesn't show transactions that spend from previous segwit outputs). I don't see that this can lead to losing money except maybe when sweeping the account with a p2pkh-only wallet and then throwing the xprv away. Of course, you can also do option 2 and let it appear to the user as if it was only one account, but what is the advantage over option 1 in that case? Also you need two xpubs to watch this joined account. Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal to update BIP-32
Am 21.04.2016 um 17:28 schrieb Eric Lombrozo: > In practice the probability of this case triggering is on the order of > 2^-128 or something astronomically tiny. I've been using BIP32 for a few > years already as have many others...I don't think we've ever had to > handle this case. Justifiably, many app developers feel like the > additional complexity of properly handling this case is not worth the > effort. > > Having said that, if the handling of this case is simple to implement > and easy to isolate in the program flow, I am in favor of doing > something along the lines of what you propose. > Yes, the idea is to handle the problem in the library so that app developers don't have to handle the case of missing addresses or just ignore the problem. It also doesn't add much complexity to the library as the current implementations already test for invalid keys. The library would then just retry instead of returning an error (that most app developers would then ignore). Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposal to update BIP-32
Hello Bitcoin Developers, I would like to make a proposal to update BIP-32 in a small way. TL;DR: BIP-32 is hard to use right (due to its requirement to skip addresses). This proposal suggests a modification such that the difficulty can be encapsulated in the library. #MOTIVATION: The current BIP-32 specifies that if for some node in the hierarchy the computed hash I_L is larger or equal to the prime or 0, then the node is invalid and should be skipped in the BIP-32 tree. This has several unfortunate consequences: - All callers of CKDpriv or CKDpub have to check for errors and handle them appropriately. This shifts the burden to the application developer instead of being able to handle it in the BIP-32 library. - It is not clear what to do if an intermediate node is missing. E.g. for the default wallet layout, if m/i_H/0 is missing should m/i_H/1 be used for external chain and m/i_H/2 for internal chain? This would make the wallet handling much more difficult. - It gets even worse with standards like BIP-44. If m/44' is missing should we use m/45' instead? If m/44'/0' is missing should we use m/44'/1' instead, using the same addresses as for testnet? One could also restart with a different seed in this case, but this wouldn't work if one later wants to support another BIP-43 proposal and still keep the same wallet. I think the first point alone is reason enough to change this. I am not aware of a BIP-32 application that handles errors like this correctly in all cases. It is also very hard to test, since it is infeasible to brute-force a BIP-32 key and a path where the node does not exists. This problem can be avoided by repeating the hashing with slightly different input data until a valid private key is found. This would be in the same spirit as RFC-6979. This way, the library will always return a valid node for all paths. Of course, in the case where the node is valid according to the current standard the behavior should be unchanged. I think the backward compatibility issues are minimal. The chance that this affects anyone is less than 10^-30. Even if it happens, it would only create some additional addresses (that are not seen if the user downgrades). The main reason for suggesting a change is that we want a similar method for different curves where a collision is much more likely. #QUESTIONS: What is the procedure to update the BIP? Is it still possible to change the existing BIP-32 even though it is marked as final? Or should I make a new BIP for this that obsoletes BIP-32? What algorithm is preferred? (bike-shedding) My suggestion: --- Change the last step of the private -> private derivation functions to: . In case parse(I_L) >= n or k_i = 0, the procedure is repeated at step 2 with I = HMAC-SHA512(Key = c_par, Data = 0x01 || I_R || ser32(i)) --- I think this suggestion is simple to implement (a bit harder to unit test) and the string to hash with HMAC-SHA512 always has the same length. I use I_R, since I_L is obviously not very random if I_L >= n. There is a minimal chance that it will lead to an infinite loop if I_R is the same in two consecutive iterations, but that has only a chance of 1 in 2^512 (if the algorithm is used for different curves that make I_L >= n more likely, the chance is still less than 1 in 2^256). In theory, this loop can be avoided by incrementing i in every iteration, but this would make an implementation error in the "hard to test" path of the program more likely. The other derivation functions should be updated in a similar matter. Also the derivation of the root node from the seed should be updated in a similar matter to avoid invalid seeds. If you followed until here, thanks for reading this long posting. Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
