Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
Hi, As I've been shown offline Twitter posts misrepresenting my previous mail, I think it's good to correct them. The security flaws are not "intentional backdoor" or whatever misrepresentation that would question the competence and know-how of the Bitcoin and Lightning development community. The replacement cycling issue discovered has been known by a small circle of Bitcoin developers since December 2022. As it appears to some experts and it has been commented publicly, changes at the bitcoin base-layer might be the most substantial fixes. Those changes take time and here this is akin to how the linux kernel, bsds and OS vendors are working [0]. All I can say is that we had recently had internal discussion on how to improve coordinated security fixes and patching processes for the coming decades. This is an area of concern where I've always been at the forefront as early as 2020 / 2021 [1]. In the meanwhile, lightning experts have already deployed mitigations which are hardening the lightning ecosystem significantly in face of simple or medium attacks. More advanced attacks can only be mounted if you have sufficient p2p and mempool knowledge as was pointed out by other bitcoin experts like Matt or Peter (which take years to acquire for average bitcoin developers) and the months of preparation to attempt them. If you're a journalist reporting on the information in mainstream crypto publications, I'll suggest waiting to do so before expert reporters of bitcoin circles who have more in-field knowledge can do so and qualify the technical situation with more distance. As I've already been interviewed by top financial publication years ago for my work on bitcoin, as a journalist you're engaging your own reputation on the information you're reporting. Thanks for being responsible here. This is the nature of the electronic communication and contemporaneous media that information is extremely fluid and there is no native anti-DoS mechanism to slow down the propagation of sensitive information where mitigations are still in deployment. A reason I'm not on social media of any kind [2]. In the meanwhile, it's good to go to read senecca and marcus aurelius take the situation with stoicism and with a zelt of meditation [3]. All my previous statements are mostly technically correct (even if some could have been written with more clarity once again I'm not an english native [4]). While I wish to wait the week of the 30th Oct o discuss further what is best fix and what are the trade-offs as a community as a wide (give time some laggard lightning implementations ship fixes), though I'll comment further on the mailing list if the flow of information on "social media" is DoSing the ability of the bitcoin community to work on the long-term appropriate fixes in a responsible and constructive fashion. [0] See meltdown class of vulnerability and how operating systems are handling hardware-sourced vulnerabilities https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability). Most of the time they do their best on the software side and they go to see with hardware vendors how to do the necessary updates. [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html [2] And for the wider analysis on contemporaneous culture of information propagation and network effect, I can only recommend to read venkatesh rao's ribbonfarm essays http://ribbonfarm.com [3] There are very good reasons why some executives at top modern technology companies are doing meditation daily, some even hours. "mind illuminated" is a good read. [4] While my former employer, Chaincode Labs, paid for my english lessons back in 2020. Generally it was a good insight from them to train people on how to communicate in a crisis. Le ven. 20 oct. 2023 à 07:56, Antoine Riard a écrit : > Hi, > > After writing the mail reply on the economics of sequential malicious > replacement of honest HTLC-timeout, I did write one more test to verify the > behavior on core mempool, and it works as expected. > > > https://github.com/ariard/bitcoin/commit/30f5d5b270e4ff195e8dcb9ef6b7ddcc5f6a1bf2 > > Responsible disclosure process has followed the lines of hardware issues > affecting operating system, as documented for the Linux kernel, while > adapted to the bitcoin ecosystem: > > https://docs.kernel.org/6.1/process/embargoed-hardware-issues.html > > Effective now, I'm halting my involvement with the development of the > lightning network and its implementations, including coordinating the > handling of security issues at the protocol level (I informed some senior > lightning devs in that sense before). > > Closed the very old issue which was affected to me at this purpose on the > bolt repository: > > https://github.com/lightning/bolts/pull/772 > > I think this new class of replacement cycling attacks puts lightning in a > very perilous position, where only a sustainable fix can happen at the > base-layer, e.g adding a memory-intensive history
Re: [bitcoin-dev] Proposed BIP for OP_CAT
Hi Greg, I didn't mean to imply this limit is a unique feature of tapescript, but rather that:OP_CAT is a tapscript opcode and that tapscript enforces a 520 byte element size thus we don't have to worry about OP_CAT creating very large stack elements. Thanks for pointing this out, I didn't realize that this limit was added in the same commit that removed OP_CAT. I thought it was more recent than that. Reading through that commit it also appears that it also reduced the size limit on inputs to arithmetic operations (nMaxNumSize) from 2064-bits to 32-bits. I had always assumed it was 32-bits from the beginning. It would have been wild to have math opcodes that support 2064-bit inputs and outputs. Thanks, Ethan On Sat, Oct 21, 2023 at 12:10 PM Greg Sanders wrote: > > This is no > longer an issue in the current age as tapscript enforces a maximum > stack element size of 520 Bytes. > > I don't think there's a new limit related to tapscript? In the very > beginning there was no limit, but a 5k limit was put into place, then 520 > the same commit that OP_CAT was > disabled: 4bd188c4383d6e614e18f79dc337fbabe8464c82 > > On Sat, Oct 21, 2023 at 1:09 AM Ethan Heilman via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi everyone, >> >> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode. >> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki >> >> OP_CAT was available in early versions of Bitcoin. It was disabled as >> it allowed the construction of a script whose evaluation could create >> stack elements exponential in the size of the script. This is no >> longer an issue in the current age as tapscript enforces a maximum >> stack element size of 520 Bytes. >> >> Thanks, >> Ethan >> >> ==Abstract== >> >> This BIP defines OP_CAT a new tapscript opcode which allows the >> concatenation of two values on the stack. This opcode would be >> activated via a soft fork by redefining the opcode OP_SUCCESS80. >> >> When evaluated the OP_CAT instruction: >> # Pops the top two values off the stack, >> # concatenate the popped values together, >> # and then pushes the concatenated value on the top of the stack. >> >> OP_CAT fails if there are less than two values on the stack or if a >> concatenated value would have a combined size of greater than the >> maximum script element size of 520 Bytes. >> >> ==Motivation== >> Bitcoin tapscript lacks a general purpose way of combining objects on >> the stack restricting the expressiveness and power of tapscript. For >> instance this prevents among many other things the ability to >> construct and evaluate merkle trees and other hashed data structures >> in tapscript. OP_CAT by adding a general purpose way to concatenate >> stack values would overcome this limitation and greatly increase the >> functionality of tapscript. >> >> OP_CAT aims to expand the toolbox of the tapscript developer with a >> simple, modular and useful opcode in the spirit of Unix[1]. To >> demonstrate the usefulness of OP_CAT below we provide a non-exhaustive >> list of some usecases that OP_CAT would enable: >> >> * Tree Signatures provide a multisignature script whose size can be >> logarithmic in the number of public keys and can encode spend >> conditions beyond n-of-m. For instance a transaction less than 1KB in >> size could support tree signatures with a thousand public keys. This >> also enables generalized logical spend conditions. [2] >> * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport >> signatures merely requires the ability to hash and concatenate values >> on the stack. [3] >> * Non-equivocation contracts [4] in tapscript provide a mechanism to >> punish equivocation/double spending in Bitcoin payment channels. >> OP_CAT enables this by enforcing rules on the spending transaction's >> nonce. The capability is a useful building block for payment channels >> and other Bitcoin protocols. >> * Vaults [5] which are a specialized covenant that allows a user to >> block a malicious party who has compromised the user's secret key from >> stealing the funds in that output. As shown in A. Poelstra, "CAT >> and Schnorr Tricks II", 2021, >> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html >> >> OP_CAT is sufficent to build vaults in Bitcoin. >> * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr >> Tricks I", 2021, >> https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 >> which would allow the creation of simple covenants and other >> advanced contracts without having to presign spending transactions, >> possibly reducing complexity and the amount of data that needs to be >> stored. Originally shown to work with Schnorr signatures, this result >> has been extended to ECDSA signatures. [6] >> >> The opcode OP_CAT was available in early versions of Bitcoin. However >> OP_CAT was removed because it enabled the construction of a script for >> which an evaluation could have memory usage
Re: [bitcoin-dev] Proposed BIP for OP_CAT
> This is no longer an issue in the current age as tapscript enforces a maximum stack element size of 520 Bytes. I don't think there's a new limit related to tapscript? In the very beginning there was no limit, but a 5k limit was put into place, then 520 the same commit that OP_CAT was disabled: 4bd188c4383d6e614e18f79dc337fbabe8464c82 On Sat, Oct 21, 2023 at 1:09 AM Ethan Heilman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi everyone, > > We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode. > https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki > > OP_CAT was available in early versions of Bitcoin. It was disabled as > it allowed the construction of a script whose evaluation could create > stack elements exponential in the size of the script. This is no > longer an issue in the current age as tapscript enforces a maximum > stack element size of 520 Bytes. > > Thanks, > Ethan > > ==Abstract== > > This BIP defines OP_CAT a new tapscript opcode which allows the > concatenation of two values on the stack. This opcode would be > activated via a soft fork by redefining the opcode OP_SUCCESS80. > > When evaluated the OP_CAT instruction: > # Pops the top two values off the stack, > # concatenate the popped values together, > # and then pushes the concatenated value on the top of the stack. > > OP_CAT fails if there are less than two values on the stack or if a > concatenated value would have a combined size of greater than the > maximum script element size of 520 Bytes. > > ==Motivation== > Bitcoin tapscript lacks a general purpose way of combining objects on > the stack restricting the expressiveness and power of tapscript. For > instance this prevents among many other things the ability to > construct and evaluate merkle trees and other hashed data structures > in tapscript. OP_CAT by adding a general purpose way to concatenate > stack values would overcome this limitation and greatly increase the > functionality of tapscript. > > OP_CAT aims to expand the toolbox of the tapscript developer with a > simple, modular and useful opcode in the spirit of Unix[1]. To > demonstrate the usefulness of OP_CAT below we provide a non-exhaustive > list of some usecases that OP_CAT would enable: > > * Tree Signatures provide a multisignature script whose size can be > logarithmic in the number of public keys and can encode spend > conditions beyond n-of-m. For instance a transaction less than 1KB in > size could support tree signatures with a thousand public keys. This > also enables generalized logical spend conditions. [2] > * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport > signatures merely requires the ability to hash and concatenate values > on the stack. [3] > * Non-equivocation contracts [4] in tapscript provide a mechanism to > punish equivocation/double spending in Bitcoin payment channels. > OP_CAT enables this by enforcing rules on the spending transaction's > nonce. The capability is a useful building block for payment channels > and other Bitcoin protocols. > * Vaults [5] which are a specialized covenant that allows a user to > block a malicious party who has compromised the user's secret key from > stealing the funds in that output. As shown in A. Poelstra, "CAT > and Schnorr Tricks II", 2021, > https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html > > OP_CAT is sufficent to build vaults in Bitcoin. > * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr > Tricks I", 2021, > https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 > which would allow the creation of simple covenants and other > advanced contracts without having to presign spending transactions, > possibly reducing complexity and the amount of data that needs to be > stored. Originally shown to work with Schnorr signatures, this result > has been extended to ECDSA signatures. [6] > > The opcode OP_CAT was available in early versions of Bitcoin. However > OP_CAT was removed because it enabled the construction of a script for > which an evaluation could have memory usage exponential in the size of > the script. > For instance a script which pushed an 1 Byte value on the stack then > repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack > value whose size was greater than 1 Terabyte. This is no longer an > issue because tapscript enforces a maximum stack element size of 520 > Bytes. > > ==Specification== > > Implementation > > if (stack.size() < 2) > return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); > valtype vch1 = stacktop(-2); > valtype vch2 = stacktop(-1); > > if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE) > return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); > > valtype vch3; > vch3.reserve(vch1.size() + vch2.size()); > vch3.insert(vch3.end(), vch1.begin(), vch1.end()); > vch3.insert(vch3.end(), vch2.begin(), vch2.end()); > > popstack(stack); >
Re: [bitcoin-dev] Proposed BIP for OP_CAT
On Sat, Oct 21, 2023 at 01:08:03AM -0400, Ethan Heilman via bitcoin-dev wrote: > Hi everyone, > > We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode. > https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki > > OP_CAT was available in early versions of Bitcoin. It was disabled as > it allowed the construction of a script whose evaluation could create > stack elements exponential in the size of the script. This is no > longer an issue in the current age as tapscript enforces a maximum > stack element size of 520 Bytes. > Thanks, Ethan! This is really great, thank you for pushing forward and writing up the BIP text. In addition to the usecases listed in the text, I think CAT would open up a wide range of Bitcoin script research and let us test nontrivial things, in perhaps inefficient ways, in real life, befoer proposing dedicated opcodes. When spitballing about ways to do cool stuff with Bitcoin Script, I'd say about 90% of the time it ends with "we could do this if only we had CAT". And the remaining 10% usually don't need much more. As evidenced by the short text and short implementation code, CAT is very simple but provides a ton of value. There is a temptation to try to bundle other opcodes in with this (for example, rolling SHA256 opcodes to allow hashing more than 520 bytes of data) but I think: * There is no logical end to the list of opcodes we'd like to add, so this will invite an interminable amount of bikeshedding. * No single opcode comes close to the power of CAT (except super general-purpose opcodes like OP_ZKP_VERIFY :)) * Most everything is more controversial than we expect. You can find Matt's "consensus cleanup" BIP from a couple years ago which did 4 small things and I think that all 4 got a bunch of pushback. So I think we should stick with "just CAT" :). -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Breaking change in calculation of hash_serialized_2
Hi Peter, to my knowledge, this was never considered as an option previously (James correct me if I am wrong). At least I couldn't find any reference to that in the original proposal [1] and I can not remember it being discussed since I have followed the project more closely (ca. 2020). Here are the reasons that I can think of why that might be the case: - If the serialization and hashing of the UTXO set works as intended, that hash should be working just as well as the flat file hash and hash_serialized_2 certainly was assumed to be robust since it has been around for a very long time. So it may simply have been viewed as additional overhead. - We may want to optimize the serialization of data to file further, adding compression, etc. to have smaller files that result in the same UTXO set without having to change the chainparams committing to that UTXO set or potentially having multiple file hashes for the same block. - We may want to introduce other file hashing strategies instead that are more optimized for P2P sharing of the UTXO snapshots. P2P sharing the UTXO set has always been part of the idea of assumeutxo but so far it hasn't been explored very deeply. For more on this see the conversation on IRC that started in the meeting yesterday between sipa, aj et al [2][3]. Cheers, Fabian [1] https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal [2] https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-10-19#976439; [3] https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-10-20#976636; --- Original Message --- On Friday, October 20th, 2023 at 7:34 PM, Peter Todd wrote: > On Fri, Oct 20, 2023 at 05:19:19PM +, Fabian via bitcoin-dev wrote: > > > Hello list, > > > > on Wednesday I found a potential malleability issue in the UTXO set dump > > files > > generated for and used by assumeutxo [1]. On Thursday morning theStack had > > found the cause of the issue [2]: A bug in the serialization of UTXOs for > > the > > calculation of hash_serialized_2. This is the value used by Bitcoin Core to > > check if the UTXO set loaded from a dump file matches what is expected. The > > value of hash_serialized_2 expected for a particular block is hardcoded into > > the chainparams of each chain. > > > > > > [1] https://github.com/bitcoin/bitcoin/issues/28675 > > [2] > > https://github.com/bitcoin/bitcoin/issues/28675#issuecomment-1770389468[3] > > https://github.com/bitcoin/bitcoin/pull/28685 > > > James made the following comment on the above issue: > > > Wow, good find @fjahr et al. I wonder if there's any value in committing to > > a > > sha256sum of the snapshot file itself in the source code as a > > belt-and-suspenders remediation for issues like this. > > > Why isn't the sha256 hash of the snapshot file itself the canonical hash? > That would obviously eliminate any malleability issues. gettxoutsetinfo > already > has to walk the entire UTXO set to calculate the hash. Making it simply > generate the actual contents of the dump file and calculate the hash of it is > the obvious way to implement this. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed BIP for OP_CAT
Hi Ethan, > [2]: P. Wuille, "Multisig on steroids using tree signatures", 2015, > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html Correct link for "Multisig on steroids using tree signatures": https://blog.blockstream.com/en-treesignatures/ /dev/fd0 floppy disk guy Sent with Proton Mail secure email. --- Original Message --- On Saturday, October 21st, 2023 at 10:38 AM, Ethan Heilman via bitcoin-dev wrote: > Hi everyone, > > We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode. > https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki > > OP_CAT was available in early versions of Bitcoin. It was disabled as > it allowed the construction of a script whose evaluation could create > stack elements exponential in the size of the script. This is no > longer an issue in the current age as tapscript enforces a maximum > stack element size of 520 Bytes. > > Thanks, > Ethan > > ==Abstract== > > This BIP defines OP_CAT a new tapscript opcode which allows the > concatenation of two values on the stack. This opcode would be > activated via a soft fork by redefining the opcode OP_SUCCESS80. > > When evaluated the OP_CAT instruction: > # Pops the top two values off the stack, > # concatenate the popped values together, > # and then pushes the concatenated value on the top of the stack. > > OP_CAT fails if there are less than two values on the stack or if a > concatenated value would have a combined size of greater than the > maximum script element size of 520 Bytes. > > ==Motivation== > Bitcoin tapscript lacks a general purpose way of combining objects on > the stack restricting the expressiveness and power of tapscript. For > instance this prevents among many other things the ability to > construct and evaluate merkle trees and other hashed data structures > in tapscript. OP_CAT by adding a general purpose way to concatenate > stack values would overcome this limitation and greatly increase the > functionality of tapscript. > > OP_CAT aims to expand the toolbox of the tapscript developer with a > simple, modular and useful opcode in the spirit of Unix[1]. To > demonstrate the usefulness of OP_CAT below we provide a non-exhaustive > list of some usecases that OP_CAT would enable: > > * Tree Signatures provide a multisignature script whose size can be > logarithmic in the number of public keys and can encode spend > conditions beyond n-of-m. For instance a transaction less than 1KB in > size could support tree signatures with a thousand public keys. This > also enables generalized logical spend conditions. [2] > * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport > signatures merely requires the ability to hash and concatenate values > on the stack. [3] > * Non-equivocation contracts [4] in tapscript provide a mechanism to > punish equivocation/double spending in Bitcoin payment channels. > OP_CAT enables this by enforcing rules on the spending transaction's > nonce. The capability is a useful building block for payment channels > and other Bitcoin protocols. > * Vaults [5] which are a specialized covenant that allows a user to > block a malicious party who has compromised the user's secret key from > stealing the funds in that output. As shown in A. Poelstra, "CAT > > and Schnorr Tricks II", 2021, > https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html > > OP_CAT is sufficent to build vaults in Bitcoin. > * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr > > Tricks I", 2021, > https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 > which would allow the creation of simple covenants and other > > advanced contracts without having to presign spending transactions, > possibly reducing complexity and the amount of data that needs to be > stored. Originally shown to work with Schnorr signatures, this result > has been extended to ECDSA signatures. [6] > > The opcode OP_CAT was available in early versions of Bitcoin. However > OP_CAT was removed because it enabled the construction of a script for > which an evaluation could have memory usage exponential in the size of > the script. > For instance a script which pushed an 1 Byte value on the stack then > repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack > value whose size was greater than 1 Terabyte. This is no longer an > issue because tapscript enforces a maximum stack element size of 520 > Bytes. > > ==Specification== > > Implementation > > > if (stack.size() < 2) > return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); > valtype vch1 = stacktop(-2); > valtype vch2 = stacktop(-1); > > if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE) > > return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); > > valtype vch3; > vch3.reserve(vch1.size() + vch2.size()); > vch3.insert(vch3.end(), vch1.begin(), vch1.end()); > vch3.insert(vch3.end(), vch2.begin(), vch2.end()); > >
Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On Fri, Oct 20, 2023 at 10:58:32PM -1000, David A. Harding wrote: > On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote: > > The basic problem here is after the HTLC-timeout path becomes spendable, > > the > > HTLC-preimage path remains spendable. That's bad, because in this case > > we want > > spending the HTLC-preimage - if possible - to have an urgency attached > > to it to > > ensure that it happens before the previous HTLC-timeout is mined. > > > > So, why can't we make the HTLC-preimage path expire? > > If the goal is to ensure the HTLC-preimage should be mined before an > upstream HTLC-timeout becomes mineable, then I don't think a consensus > change is required. We can just make the HTLC-preimage claimable by anyone > some time after the HTLC-timeout becomes mineable. > > For example, imagine that Alice offers Bob an HTLC with a timeout at block > t+200. Bob offers Carol an HTLC with a timeout at block t+100. The > Bob-Carol HTLC script looks like this: > > If > # Does someone have the preimage? > Hash EqualVerify > If > # Carol has the preimage at any time > CheckSig > Else > # Anyone else has the preimage after t+150 > CLTV > EndIf > Else > # Bob is allowed a refund after t+100 >CheckSigVerify >CLTV > EndIf > > In English: > > - At any time, Carol can spend the output by releasing the preimage > - After t+100, Bob can spend the output > - After t+150, anyone with the preimage can spend the output This is a clever idea. But it doesn't prevent this attack. Think about it this way: where previously there was one Carol who could perform the replacement cycling attack, with the anyone-can-spend branch the situation eventually transforms into a situation where there is an unlimited set of Carols who can perform the attack and, if they are a miner, benefit from it. Either way Bob is in a position where they might not learn about the preimage in time, and thus fail to redeem the received HTLC output. From Carol's point of view the situation didn't significantly change. Either they manage to succesfully spend the offered HTLC output after the redeemed HTLC output times out. Or they fail. Whether or not that failure happens because Bob got their refund, or someone else spent the offered HTLC output via the anyone-can-spend path is not relevant to Carol. Finally, this solution is inferior to OP_Expire in another important way: the anyone-can-spend branch represents a strict deadline for Bob too. With OP_Expire, once HTLC preimage branch has expired, Bob can spend the offered HTLC output at their leisure, as they are the only party with the ability to do that (assuming of course that we're talking about a valid commitment transaction, not an illegitmate revoked once). > [2] Although miners may want to consider running code that allows them to > rewrite any malleable transactions to pay themselve With full-RBF _anyone_ can run that code on behalf of miners, modulo edge cases where the replacement isn't possible due to the RBF anti-DoS rules. Indeed, people are apparently already doing this to screw over signature-less ordinal transactions. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote: The basic problem here is after the HTLC-timeout path becomes spendable, the HTLC-preimage path remains spendable. That's bad, because in this case we want spending the HTLC-preimage - if possible - to have an urgency attached to it to ensure that it happens before the previous HTLC-timeout is mined. So, why can't we make the HTLC-preimage path expire? If the goal is to ensure the HTLC-preimage should be mined before an upstream HTLC-timeout becomes mineable, then I don't think a consensus change is required. We can just make the HTLC-preimage claimable by anyone some time after the HTLC-timeout becomes mineable. For example, imagine that Alice offers Bob an HTLC with a timeout at block t+200. Bob offers Carol an HTLC with a timeout at block t+100. The Bob-Carol HTLC script looks like this: If # Does someone have the preimage? Hash EqualVerify If # Carol has the preimage at any time CheckSig Else # Anyone else has the preimage after t+150 CLTV EndIf Else # Bob is allowed a refund after t+100 CheckSigVerify CLTV EndIf In English: - At any time, Carol can spend the output by releasing the preimage - After t+100, Bob can spend the output - After t+150, anyone with the preimage can spend the output Let's consider this in the wider context of the forwarded payment Alice->Bob->Carol: - If Carol attempts to spend the output by releasing the preimage but pays too low of a feerate to get it confirmed by block t+100, Bob can spend the output in block t+101. He then has 99 blocks to settle (revoke) the Alice-Bob HTLC offchain. - If Carol releases the preimage to the network in general but prevents Bob from using it (e.g. using a replacement cycling attack), anyone who saw the preimage can take Carol's output at t+150 and, by doing so, will put the preimage in the block chain where Bob will learn about it. He'll then have 49 blocks to settle (revoke) the Alice-Bob HTLC offchain. - (All the normal cases when the HTLC is settled offchain, or where onchain operations occur in a timely manner) I think that adequately satisfies the concern about the effect on LN from replacement cycling. Looking at potential complications: - If all miners acted together[1], they are incentivized to not mine Carol's preimage transaction before t+150 because its fees are less than the HTLC value they can receive at t+150. I think this level of miner centralization would result in a general failure for LN given that miners could be any LN user's counterparty (or bribed by a user's counterparty). E.g., stuff like this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017997.html - To allow anyone with the preimage to spend the output after t+150, they need to know the script. For taproot, that means the t+150 tapleaf script needs to follow a standard (e.g. a BOLT) and that any internal merkle nodes needed to connect it to the taproot commitment need to be shown in Carol's preimage transaction (or inferable from it or other data). - Classic RBF pinning of the t+150 transaction to prevent it from confirming by block t+200 might be an issue. E.g., including it in a 400,000 weight low-feerate transaction. - Full RBF might be required to ensure the t+150 transaction isn't sent with a low feerate and no opt-in signal. Deployment considerations: - No changes are required to full nodes (no consensus change required) - No changes are required to mining Bitcoin nodes[2] - At least one well-connected Bitcoin relay node will need to be updated to store preimages and related data, and to send the preimage claim transactions. Data only needs to be kept for a rolling window of a few thousand blocks for the LN case, bounding storage requirements. No changes are required to other relaying Bitcoin nodes - LN nodes will need to update to new HTLC scripts, but this should be doable without closing/re-opening channels. Both anchor and non-anchor channels can continue to be used Compared to OP_EXPIRE: - OP_EXPIRE requires consensus and policy changes; this does not - OP_EXPIRE does not depend on special software; this depends on at least one person running special software Although this proposal is an alternative to Peter's proposal and is primarily inspired by his idea, it's also a variation on a previous suggestion of mine: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html -Dave [1] Perhaps under block censorship threat from a mining majority or a sub-majority performing selfish mining. [2] Although miners may want to consider running code that allows them to rewrite any malleable transactions to pay themselve ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
