*[bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)@ 2024-04-29 0:30 Ethan Heilman2024-04-30 12:32 ` Matthew Zipkin 0 siblings, 1 reply; 18+ messages in thread From: Ethan Heilman @ 2024-04-29 0:30 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 13647 bytes --] One day having lunch at the MIT DCI and discussing OP_CAT and lamport signatures we came up with a scheme to do lamport signatures on Bitcoin transactions without OP_CAT. This scheme has the following properties: 1. Should work with today's Bitcoin (no OP_CAT required). 2. Unlike other lamport signatures in Bitcoin script, this scheme signs the spending transaction. Disclaimer: This is very preliminary work and the security of these signatures rests on a number of simplifying assumptions about ECDSA signatures that may not be true. Do not use this signature scheme in a Bitcoin output unless your intent is for that output to be a fun crypto bounty. I have not tested this in Bitcoin script. This idea of using signature length shares a lot in common with sigPOW (signature POW) proposed by Robin Linus [3,4] and implemented by VzxPLnHqr [5] which uses signature length grinding as a transaction level POW mechanism and earlier work by Anthony Towns and Greg Maxwell using ECDSA signature length constraints to force revealing signing key [6]. Our approach differs from the Jeremy Rubin's approach in [7] as we do not require OP_CAT and we use P2SH not tapscript and from Jeremy Rubin's approach in [8] as our goal is to verify a Lamport signature on the spending transaction rather than a Lamport signature on arbitrary data. When compared with [7,8] our scheme is far less practical as it requires very large numbers of signatures (below we discuss 1000 signatures). ## Signing a Bitcoin Transaction with Lamport Signatures An ECDSA signature (r,s) is calculated as r = (k*G)_x, s= (z+r*dA)/k - k is randomly chosen nonce - dA is the signing key, - z is derived from the hash of the signed message, i.e., transaction hash. Our Lamport scheme is based on the following observation. ECDSA signatures in bitcoin are variable in length and that the length of an s-value in an ECDSA signature for a fixed nonce, k, and fixed signing key has its length determined by the transaction hash. We can use OP_SIZE to get the size of a signature and we can use Lamport signatures to sign this size. We explain Lamport signatures below. The security of our scheme rests on a way to fix the nonce k. Madars Virza and Andrew Poelstra both pointed out to me when discussing this scheme that setting k=1/2, that is setting k to the multiplicative inverse of 2, results in a k with a very short r (r=0x00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63) [0]. This means that the first 11 bytes (88-bits of the r value are zero and truncated) so the r-value is only 21 bytes long! A publicly known k leaks the signing key, but that doesn't matter for our purposes. Using this k, we can ensure that the r values on two signatures are the same by inspecting their length using `OP_SIZE(sig) < (21+32+6)`. Grinding r to find a smaller value requires 2^96 (12 bytes of zeros) computations assuming no mathematical shortcut such as the one used to find k=1/2. To explain how to use the above observative to sign Bitcoin transactions with Lamport signatures, let's remind ourselves how Lamport signatures [1] work. To sign 1-bit with a Lamport signature you first use a hash function H, to compute: x0 = H(y0), x1 = H(y1). Next, you publish x0,x1 as your public key. Then, to sign the bit 0, you release the value y0. Anyone can use y0 to verify that x0 == H(y0). To sign the bit 1, you release y1. We use Lamport signatures to sign the length of a bitcoin signature. The length of the signature serves as a proxy for the transaction hash of the spending transaction. Repeating this many times provides cryptographic levels of security. Let's look at an example: Alice computes her Lamport public keys and signing keys x00 = Hash(y00) x01 = Hash(y01) x10 = Hash(y10) x11 = Hash(y11) x20 = Hash(y20) x21 = Hash(y21) In pseudocode Alice's redeem script looks like: ``` PUSH ecdsaPubkey0 OP_CHECKSIG (ecdsaSig0) // Verify lamport signature on ecdsaSig0 PUSH x00, x01 if OP_SIZE (ecdsaSig0) == 59: if OP_HASH(y00) != x00: OP_RETURN else if OP_SIZE (ecdsaSig0) < 59: if OP_HASH(y01) != x01: OP_RETURN PUSH ecdsaPubkey1 OP_CHECKSIG (ecdsaSig1) // Verify lamport signature on ecdsaSig1 PUSH x10, x11 if OP_SIZE (ecdsaSig1) == 59: if OP_HASH(y10) != x10: OP_RETURN else if OP_SIZE (ecdsaSig1) < 59: if OP_HASH(y11) != x11: OP_RETURN // Verify lamport signature on ecdsaSig2 PUSH ecdsaPubkey2 OP_CHECKSIG (ecdsaSig2) // Verify lamport signature on ecdsaSig1 PUSH x20, x21 if OP_SIZE (ecdsaSig2) == 59: if OP_HASH(y20) != x10: OP_RETURN else if OP_SIZE (ecdsaSig2) < 59: if OP_HASH(y21) != x21: OP_RETURN ``` Alice computes the ECDSA signatures: ecdsaSig0, ecdsaSig1, ecdsaSig2. For example let’s say OP_SIZE(ecdsaSig0)=59, OP_SIZE(ecdsaSig1)=58, OP_SIZE(ecdsaSig2)=59. Thus, to spend she generates a Lamport signature over those lengths by releasing the preimages: y00, y11, y20. The spend script pseudocode: ``` PUSH ecdsaSig0 PUSH y00 // Signs that OP_SIZE(ecdsaSig0) should be 59 PUSH ecdsaSig1 PUSH y11 // Signs that OP_SIZE(ecdsaSig1) should be less than 59 PUSH ecdsaSig2 PUSH y20 // Signs that OP_SIZE(ecdsaSig2) should be 59 ``` The advantage Alice has over an attacker attempting to steal her funds is that all Alice has to do is release the preimages for the lengths of all of her ECDSA signatures, but an attacker has to construct a transaction hash that matches the size of her signatures for each different ECDSA signature. The probability an attacker manages this for three random ECDSA signatures given the lengths above (59,58,59) is 255/256 * 1/256 * 255/256 ~= 0.3%. Alice can arbitrarily amplify her security by adding additional ECDSA signatures. It was pointed out to me by Andrew Poelstra that the probability that a random signature is shorter by one byte is 1/256 because OP_SIZE only measures the byte length of a value, not the bit length. This means most of the time if Alice just used three ECDSA signatures, they would all be length 59. In such a case the attacker would have (255/256)^3 = 98% probability of generating a transaction that can be spent using Alice's signature on the attacker's very first try! For this reason Alice really needs a lot of ECDSA signatures and probably also needs to grind for safer values to sign (safer = high diversity in length). Assuming a simplistic model of ECDSA signatures length Prob(1-1/256) for length 59 and Prob(1/256) for length <59, the probability that Alice will generate exactly m <59-length signatures and n-m 59 length signatures is: `(255/256)^(n-m)*(1/256)^m*(n choose m)`. An attacker would need to not only generate m <59-length signatures and n-m 59 length signatures, but generate them in the same position as Alice generated them. The probability an attacker will generate exactly m <59-length signatures and n-m 59 length signatures in the same position as Alice is: (255/256)^(n-m)*(1/256)^m On average Alice would need 1000 attempts to sign with n=800,m=10. Whereas an attacker would need to make 2^84 attempts to brute force the output after seeing alice attempt to spend that output using a n=800,m=10 signature. ## Known weaknesses 1. *The Tuning Attack:* The attacker can use different SIG_HASH flags per signature to attack each signature individually. For instance ecdsaSig1 doesn't have the right length, the attacker can try SIGHASH_NONE to try again without changing any of the other signature lengths. This provides the attacker some advantage but with sufficient numbers of signatures it does not break the scheme. Alice can also use this approach to increase the security of her signatures by increasing length diversity. Unclear if this helps or hurts security more. 2. *Mix and Match Attack:* Even if an attacker can not grind a shorter r-value, an r-value of roughly 21-23 bytes would allow an attacker to make a few more individual attempts on a particular signature length. This is because we only measure the total length of the ECDSA signature, so a 23-byte r-value combined with a 29-byte s-value would be 23+29+6 = 58 bytes. 29-byte s-value are rare and occur with ~1/2^24 probability, but if an attacker managed to grind a 23-byte r-value at a cost of 2^72 computations, it would provide the attacker some advantage. ## Known Improvements 1. Rather than only signing if the length is 59 or less. We could extend the scheme to sign multiple ECDSA signature length values, 59, 58, 57, 56... This could enable Alice to greatly increase her security as say 56 would only occur 1 out of every 2^32 signatures. Winternitz One Time signatures (WOTs) [2] could be used here to compress signature length. 1. Jeremy Rubun suggested the following optimization: rather than directly signing the ECDSA signatures lengths, you construct a 32-bit bit vector of the signature lengths using OP_MUL, OP_ADD. bit vector = OP_SIZE(ecdsaSig0)==59 + 2*(OP_SIZE(ecdsaSig1)==59) + 4*(OP_SIZE(ecdsaSig2)==59) ... Then you compute a Winternitz One Time signature over this bit vector. This would require also computing a WInternitz or Lamport signature over a checksum of the bit vector. This would substantially reduce the number of lamport public keys and signing keys and likely reduce the size of redeem script and spend script by half. 3. Since 59 is the default length, Alice does not in fact need to sign 59. It could be inferred that if no preimage is given or say the preimage 0 is given, the length that Alice intends is 59. This would save space on the spend script and redeem script. ## Open Questions 1. Could OP_CODESEPARATOR be used by Alice or the attacker to either strengthen or weaken the security of this scheme. Alice using OP_CODESEPARATOR to strengthen the security of this scheme by increasing signature length diversity was suggested by Jeremy Rubin. After some discussion, the fact that the redeem script is part of the P2SH address means that the data in OP_CODESEPARATOR would still influence all the other ECDSA signatures. That said, perhaps there is some way it can be exploited to either help Alice or help the attacker. 2. If a nonce value k was discovered such that k*G = r = 1, we could remove the assumption that no could find a smaller r. It is unknown how to find r=1 as it requires finding the discrete log. It is possible to create transaction signatures that have r=1 without knowing k, through the use of ECDSA pubkey recovery. This does not work for our scheme as we must commit to the ECDSA public key in the spent transaction. Are there any known smaller r values than r=1/2*G? 3. How many bits of security does each ECDSA signature contribute in this scheme given the SIGHASH mix and match attack above? How many ECDSA signatures are needed? We have modeled ECDSA s-values signatures being uniformly drawn from 2^256. It seems unlikely to me that the Elliptic Curve math lines up perfectly with a 256 bit space especially for a fixed r-value that has special mathematical properties. Non-uniformity here could end up helping (increasing length diversity) or hurting (a pattern an attacker could exploit to match the length faster than brute force) the security. 4. An attacker could trade off brute forcing the transaction hash lengths by computing a small r-value. What does the time-memory trade look like here? 5. Is there any use for this beyond a fun party trick? Thanks to Madars Virza, Dan Gould, Armin Sabouri, Neha Narula, Jeremy Rubin, Andrew Poelstra, Robin Linus for discussing this with me and giving me feedback. This initial discuss was fueled by the MIT DCI espresso machine. I've attempted to credit all ideas contributed to the contributor, if I got this wrong or missed a contribution shoot me an email. Any mistakes are my own as I wrote this up. [0]: "Bitcoin Wallet Recovery via ECDSA Short Signatures" https://github.com/demining/Bitcoin-Wallet-Recovery?tab=readme-ov-file [1]: "Constructing Digital Signatures from a One Way Function", Leslie Lamport (1979), https://www.microsoft.com/en-us/research/publication/constructing-digital-signatures-one-way-function/ [2]: "A Certified Digital Signature", Ralph C. Merkle (1979), https://www.ralphmerkle.com/papers/Certified1979.pdf [3]: "Timelocked Proof of Work via signature length", Robin Linus (2021), https://gist.github.com/RobinLinus/95de641ed1e3d9fde83bdcf5ac289ce9#file-sig_pow-md [4]: "Proof of Work in Bitcoin Script", Robin Linus (2020), https://github.com/coins/bitcoin-scripts/blob/master/proof-of-work.md [5]: "sig-pow - work-locked outputs", VzxPLnHqr (2022), https://github.com/VzxPLnHqr/sig-pow/ [6]: "[Lightning-dev] Better privacy with SNARKs", Anthony Towns (2015), https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html [7]: "Quantum Proofing Bitcoin with a CAT", Jeremy Rubin (2021), https://rubin.io/blog/2021/07/06/quantum-bitcoin/ [8]: "CheckSigFromStack for 5 Byte Values", Jeremy Rubin (2021), https://rubin.io/blog/2021/07/02/signing-5-bytes/ -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BXyW8wNOekw13C5jDMzQ-dOJpQrBC%2BqR8-uDot25tM%3DXA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 15004 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-04-29 0:30 [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) Ethan Heilman@ 2024-04-30 12:32 ` Matthew Zipkin2024-04-30 13:25 ` Ethan Heilman 2024-04-30 14:21 ` Andrew Poelstra 0 siblings, 2 replies; 18+ messages in thread From: Matthew Zipkin @ 2024-04-30 12:32 UTC (permalink / raw) To: Ethan Heilman;+Cc:Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 15240 bytes --] We discussed this scheme at NY BitDevs last night and one participant made a great point: > if an attacker managed to grind a 23-byte r-value at a cost of 2^72 computations, it would provide the attacker some advantage. If we are assuming discrete log is still hard, why do we need Lamport signatures at all? In a post-quantum world, finding k such that r is 21 bytes or less is efficient for the attacker. On Sun, Apr 28, 2024 at 8:50 PM Ethan Heilman <eth3rs@gmail.com> wrote: > One day having lunch at the MIT DCI and discussing OP_CAT and lamport > signatures we came up with a scheme to do lamport signatures on Bitcoin > transactions without OP_CAT. > > This scheme has the following properties: > 1. Should work with today's Bitcoin (no OP_CAT required). > 2. Unlike other lamport signatures in Bitcoin script, this scheme signs > the spending transaction. > > Disclaimer: This is very preliminary work and the security of these > signatures rests on a number of simplifying assumptions about ECDSA > signatures that may not be true. Do not use this signature scheme in a > Bitcoin output unless your intent is for that output to be a fun crypto > bounty. I have not tested this in Bitcoin script. > > This idea of using signature length shares a lot in common with sigPOW > (signature POW) proposed by Robin Linus [3,4] and implemented by VzxPLnHqr > [5] which uses signature length grinding as a transaction level POW > mechanism and earlier work by Anthony Towns and Greg Maxwell using ECDSA > signature length constraints to force revealing signing key [6]. > > Our approach differs from the Jeremy Rubin's approach in [7] as we do not > require OP_CAT and we use P2SH not tapscript and from Jeremy Rubin's > approach in [8] as our goal is to verify a Lamport signature on the > spending transaction rather than a Lamport signature on arbitrary data. > When compared with [7,8] our scheme is far less practical as it requires > very large numbers of signatures (below we discuss 1000 signatures). > > ## Signing a Bitcoin Transaction with Lamport Signatures > > An ECDSA signature (r,s) is calculated as r = (k*G)_x, s= (z+r*dA)/k > - k is randomly chosen nonce > - dA is the signing key, > - z is derived from the hash of the signed message, i.e., transaction hash. > > Our Lamport scheme is based on the following observation. ECDSA signatures > in bitcoin are variable in length and that the length of an s-value in an > ECDSA signature for a fixed nonce, k, and fixed signing key has its length > determined by the transaction hash. We can use OP_SIZE to get the size of a > signature and we can use Lamport signatures to sign this size. We explain > Lamport signatures below. > > The security of our scheme rests on a way to fix the nonce k. Madars Virza > and Andrew Poelstra both pointed out to me when discussing this scheme that > setting k=1/2, that is setting k to the multiplicative inverse of 2, > results in a k with a very short r > (r=0x00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63) [0]. > This means that the first 11 bytes (88-bits of the r value are zero and > truncated) so the r-value is only 21 bytes long! A publicly known k leaks > the signing key, but that doesn't matter for our purposes. > > Using this k, we can ensure that the r values on two signatures are the > same by inspecting their length using `OP_SIZE(sig) < (21+32+6)`. Grinding > r to find a smaller value requires 2^96 (12 bytes of zeros) computations > assuming no mathematical shortcut such as the one used to find k=1/2. > > > To explain how to use the above observative to sign Bitcoin transactions > with Lamport signatures, let's remind ourselves how Lamport signatures [1] > work. To sign 1-bit with a Lamport signature you first use a hash function > H, to compute: x0 = H(y0), x1 = H(y1). Next, you publish x0,x1 as your > public key. Then, to sign the bit 0, you release the value y0. Anyone can > use y0 to verify that x0 == H(y0). To sign the bit 1, you release y1. > > We use Lamport signatures to sign the length of a bitcoin signature. The > length of the signature serves as a proxy for the transaction hash of the > spending transaction. Repeating this many times provides cryptographic > levels of security. Let's look at an example: > > Alice computes her Lamport public keys and signing keys > x00 = Hash(y00) > x01 = Hash(y01) > x10 = Hash(y10) > x11 = Hash(y11) > x20 = Hash(y20) > x21 = Hash(y21) > > In pseudocode Alice's redeem script looks like: > ``` > PUSH ecdsaPubkey0 > OP_CHECKSIG (ecdsaSig0) > // Verify lamport signature on ecdsaSig0 > PUSH x00, x01 > if OP_SIZE (ecdsaSig0) == 59: > if OP_HASH(y00) != x00: OP_RETURN > else if OP_SIZE (ecdsaSig0) < 59: > if OP_HASH(y01) != x01: OP_RETURN > > PUSH ecdsaPubkey1 > OP_CHECKSIG (ecdsaSig1) > // Verify lamport signature on ecdsaSig1 > PUSH x10, x11 > if OP_SIZE (ecdsaSig1) == 59: > if OP_HASH(y10) != x10: OP_RETURN > else if OP_SIZE (ecdsaSig1) < 59: > if OP_HASH(y11) != x11: OP_RETURN > > // Verify lamport signature on ecdsaSig2 > PUSH ecdsaPubkey2 > OP_CHECKSIG (ecdsaSig2) > // Verify lamport signature on ecdsaSig1 > PUSH x20, x21 > if OP_SIZE (ecdsaSig2) == 59: > if OP_HASH(y20) != x10: OP_RETURN > else if OP_SIZE (ecdsaSig2) < 59: > if OP_HASH(y21) != x21: OP_RETURN > ``` > > Alice computes the ECDSA signatures: ecdsaSig0, ecdsaSig1, ecdsaSig2. For > example let’s say OP_SIZE(ecdsaSig0)=59, OP_SIZE(ecdsaSig1)=58, > OP_SIZE(ecdsaSig2)=59. Thus, to spend she generates a Lamport signature > over those lengths by releasing the preimages: y00, y11, y20. > > The spend script pseudocode: > ``` > PUSH ecdsaSig0 > PUSH y00 // Signs that OP_SIZE(ecdsaSig0) should be 59 > PUSH ecdsaSig1 > PUSH y11 // Signs that OP_SIZE(ecdsaSig1) should be less than 59 > PUSH ecdsaSig2 > PUSH y20 // Signs that OP_SIZE(ecdsaSig2) should be 59 > ``` > > The advantage Alice has over an attacker attempting to steal her funds is > that all Alice has to do is release the preimages for the lengths of all of > her ECDSA signatures, but an attacker has to construct a transaction hash > that matches the size of her signatures for each different ECDSA signature. > The probability an attacker manages this for three random ECDSA signatures > given the lengths above (59,58,59) is 255/256 * 1/256 * 255/256 ~= 0.3%. > Alice can arbitrarily amplify her security by adding additional ECDSA > signatures. > > It was pointed out to me by Andrew Poelstra that the probability that a > random signature is shorter by one byte is 1/256 because OP_SIZE only > measures the byte length of a value, not the bit length. This means most of > the time if Alice just used three ECDSA signatures, they would all be > length 59. In such a case the attacker would have (255/256)^3 = 98% > probability of generating a transaction that can be spent using Alice's > signature on the attacker's very first try! > > For this reason Alice really needs a lot of ECDSA signatures and probably > also needs to grind for safer values to sign (safer = high diversity in > length). > > Assuming a simplistic model of ECDSA signatures length Prob(1-1/256) for > length 59 and Prob(1/256) for length <59, the probability that Alice will > generate exactly m <59-length signatures and n-m 59 length signatures is: > `(255/256)^(n-m)*(1/256)^m*(n choose m)`. > > An attacker would need to not only generate m <59-length signatures and > n-m 59 length signatures, but generate them in the same position as Alice > generated them. The probability an attacker will generate exactly m > <59-length signatures and n-m 59 length signatures in the same position as > Alice is: (255/256)^(n-m)*(1/256)^m > > On average Alice would need 1000 attempts to sign with n=800,m=10. Whereas > an attacker would need to make 2^84 attempts to brute force the output > after seeing alice attempt to spend that output using a n=800,m=10 > signature. > > ## Known weaknesses > > 1. *The Tuning Attack:* The attacker can use different SIG_HASH flags per > signature to attack each signature individually. For instance ecdsaSig1 > doesn't have the right length, the attacker can try SIGHASH_NONE to try > again without changing any of the other signature lengths. This provides > the attacker some advantage but with sufficient numbers of signatures it > does not break the scheme. Alice can also use this approach to increase the > security of her signatures by increasing length diversity. Unclear if this > helps or hurts security more. > > 2. *Mix and Match Attack:* Even if an attacker can not grind a shorter > r-value, an r-value of roughly 21-23 bytes would allow an attacker to make > a few more individual attempts on a particular signature length. This is > because we only measure the total length of the ECDSA signature, so a > 23-byte r-value combined with a 29-byte s-value would be 23+29+6 = 58 > bytes. 29-byte s-value are rare and occur with ~1/2^24 probability, but if > an attacker managed to grind a 23-byte r-value at a cost of 2^72 > computations, it would provide the attacker some advantage. > > ## Known Improvements > > 1. Rather than only signing if the length is 59 or less. We could extend > the scheme to sign multiple ECDSA signature length values, 59, 58, 57, > 56... This could enable Alice to greatly increase her security as say 56 > would only occur 1 out of every 2^32 signatures. Winternitz One Time > signatures (WOTs) [2] could be used here to compress signature length. > > 1. Jeremy Rubun suggested the following optimization: rather than directly > signing the ECDSA signatures lengths, you construct a 32-bit bit vector of > the signature lengths using OP_MUL, OP_ADD. > > bit vector = OP_SIZE(ecdsaSig0)==59 + 2*(OP_SIZE(ecdsaSig1)==59) + > 4*(OP_SIZE(ecdsaSig2)==59) ... > > Then you compute a Winternitz One Time signature over this bit vector. > This would require also computing a WInternitz or Lamport signature over a > checksum of the bit vector. This would substantially reduce the number of > lamport public keys and signing keys and likely reduce the size of redeem > script and spend script by half. > > 3. Since 59 is the default length, Alice does not in fact need to sign 59. > It could be inferred that if no preimage is given or say the preimage 0 is > given, the length that Alice intends is 59. This would save space on the > spend script and redeem script. > > > ## Open Questions > > 1. Could OP_CODESEPARATOR be used by Alice or the attacker to either > strengthen or weaken the security of this scheme. Alice using > OP_CODESEPARATOR to strengthen the security of this scheme by increasing > signature length diversity was suggested by Jeremy Rubin. After some > discussion, the fact that the redeem script is part of the P2SH address > means that the data in OP_CODESEPARATOR would still influence all the other > ECDSA signatures. That said, perhaps there is some way it can be exploited > to either help Alice or help the attacker. > > 2. If a nonce value k was discovered such that k*G = r = 1, we could > remove the assumption that no could find a smaller r. It is unknown how to > find r=1 as it requires finding the discrete log. It is possible to create > transaction signatures that have r=1 without knowing k, through the use of > ECDSA pubkey recovery. This does not work for our scheme as we must commit > to the ECDSA public key in the spent transaction. Are there any known > smaller r values than r=1/2*G? > > 3. How many bits of security does each ECDSA signature contribute in this > scheme given the SIGHASH mix and match attack above? How many ECDSA > signatures are needed? We have modeled ECDSA s-values signatures being > uniformly drawn from 2^256. It seems unlikely to me that the Elliptic Curve > math lines up perfectly with a 256 bit space especially for a fixed r-value > that has special mathematical properties. Non-uniformity here could end up > helping (increasing length diversity) or hurting (a pattern an attacker > could exploit to match the length faster than brute force) the security. > > 4. An attacker could trade off brute forcing the transaction hash lengths > by computing a small r-value. What does the time-memory trade look like > here? > > 5. Is there any use for this beyond a fun party trick? > > Thanks to Madars Virza, Dan Gould, Armin Sabouri, Neha Narula, Jeremy > Rubin, Andrew Poelstra, Robin Linus for discussing this with me and giving > me feedback. This initial discuss was fueled by the MIT DCI espresso > machine. I've attempted to credit all ideas contributed to the contributor, > if I got this wrong or missed a contribution shoot me an email. Any > mistakes are my own as I wrote this up. > > [0]: "Bitcoin Wallet Recovery via ECDSA Short Signatures" > https://github.com/demining/Bitcoin-Wallet-Recovery?tab=readme-ov-file > > [1]: "Constructing Digital Signatures from a One Way Function", Leslie > Lamport (1979), > https://www.microsoft.com/en-us/research/publication/constructing-digital-signatures-one-way-function/ > > [2]: "A Certified Digital Signature", Ralph C. Merkle (1979), > https://www.ralphmerkle.com/papers/Certified1979.pdf > > [3]: "Timelocked Proof of Work via signature length", Robin Linus (2021), > https://gist.github.com/RobinLinus/95de641ed1e3d9fde83bdcf5ac289ce9#file-sig_pow-md > > [4]: "Proof of Work in Bitcoin Script", Robin Linus (2020), > https://github.com/coins/bitcoin-scripts/blob/master/proof-of-work.md > > [5]: "sig-pow - work-locked outputs", VzxPLnHqr (2022), > https://github.com/VzxPLnHqr/sig-pow/ > > [6]: "[Lightning-dev] Better privacy with SNARKs", Anthony Towns (2015), > https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html > > [7]: "Quantum Proofing Bitcoin with a CAT", Jeremy Rubin (2021), > https://rubin.io/blog/2021/07/06/quantum-bitcoin/ > > [8]: "CheckSigFromStack for 5 Byte Values", Jeremy Rubin (2021), > https://rubin.io/blog/2021/07/02/signing-5-bytes/ > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BXyW8wNOekw13C5jDMzQ-dOJpQrBC%2BqR8-uDot25tM%3DXA%40mail.gmail.com > <https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BXyW8wNOekw13C5jDMzQ-dOJpQrBC%2BqR8-uDot25tM%3DXA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CA%2Bx5asTOTai_4yNGEgtKEqAchuWJ0jGDEgMqHFYDwactPnrgyw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 16697 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-04-30 12:32 ` Matthew Zipkin@ 2024-04-30 13:25 ` Ethan Heilman2024-04-30 14:21 ` Andrew Poelstra 1 sibling, 0 replies; 18+ messages in thread From: Ethan Heilman @ 2024-04-30 13:25 UTC (permalink / raw) To: Matthew Zipkin;+Cc:Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 16642 bytes --] > If we are assuming discrete log is still hard, why do we need Lamport signatures at all? In a post-quantum world, finding k such that r is 21 bytes or less is efficient for the attacker. This is true, however there is a fix. Someone at the DCI, I think Madars, pointed out that if you had a quantum computer you could find r=1 and then everyone could use r=1 in the scheme and not have to worry about grinding attacks. So the ability to compute discrete logs would strengthen this scheme. Interestingly, you can generate valid ecdsa signatures where (r=1,s=1) using ecdsa pubkey recovery because "An ECDSA signature itself does not prove knowledge of a discrete log." <https://bitcointalk.org/index.php?topic=1729534.msg17309060#msg17309060> I am not aware of any technique, even if we had OP_LAMPORT, to make Bitcoin outputs quantum resistant without a softfork to add the ability to disable key-spend paths in a taproot output. I'd love to be proven wrong on this point. On Tue, Apr 30, 2024 at 8:32 AM Matthew Zipkin <pinheadmz@gmail.com> wrote: > We discussed this scheme at NY BitDevs last night and one participant made > a great point: > > > if an attacker managed to grind a 23-byte r-value at a cost of 2^72 > computations, it would provide the attacker some advantage. > > If we are assuming discrete log is still hard, why do we need Lamport > signatures at all? In a post-quantum world, finding k such that r is 21 > bytes or less is efficient for the attacker. > > > On Sun, Apr 28, 2024 at 8:50 PM Ethan Heilman <eth3rs@gmail.com> wrote: > >> One day having lunch at the MIT DCI and discussing OP_CAT and lamport >> signatures we came up with a scheme to do lamport signatures on Bitcoin >> transactions without OP_CAT. >> >> This scheme has the following properties: >> 1. Should work with today's Bitcoin (no OP_CAT required). >> 2. Unlike other lamport signatures in Bitcoin script, this scheme signs >> the spending transaction. >> >> Disclaimer: This is very preliminary work and the security of these >> signatures rests on a number of simplifying assumptions about ECDSA >> signatures that may not be true. Do not use this signature scheme in a >> Bitcoin output unless your intent is for that output to be a fun crypto >> bounty. I have not tested this in Bitcoin script. >> >> This idea of using signature length shares a lot in common with sigPOW >> (signature POW) proposed by Robin Linus [3,4] and implemented by VzxPLnHqr >> [5] which uses signature length grinding as a transaction level POW >> mechanism and earlier work by Anthony Towns and Greg Maxwell using ECDSA >> signature length constraints to force revealing signing key [6]. >> >> Our approach differs from the Jeremy Rubin's approach in [7] as we do not >> require OP_CAT and we use P2SH not tapscript and from Jeremy Rubin's >> approach in [8] as our goal is to verify a Lamport signature on the >> spending transaction rather than a Lamport signature on arbitrary data. >> When compared with [7,8] our scheme is far less practical as it requires >> very large numbers of signatures (below we discuss 1000 signatures). >> >> ## Signing a Bitcoin Transaction with Lamport Signatures >> >> An ECDSA signature (r,s) is calculated as r = (k*G)_x, s= (z+r*dA)/k >> - k is randomly chosen nonce >> - dA is the signing key, >> - z is derived from the hash of the signed message, i.e., transaction >> hash. >> >> Our Lamport scheme is based on the following observation. ECDSA >> signatures in bitcoin are variable in length and that the length of an >> s-value in an ECDSA signature for a fixed nonce, k, and fixed signing key >> has its length determined by the transaction hash. We can use OP_SIZE to >> get the size of a signature and we can use Lamport signatures to sign this >> size. We explain Lamport signatures below. >> >> The security of our scheme rests on a way to fix the nonce k. Madars >> Virza and Andrew Poelstra both pointed out to me when discussing this >> scheme that setting k=1/2, that is setting k to the multiplicative inverse >> of 2, results in a k with a very short r >> (r=0x00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63) [0]. >> This means that the first 11 bytes (88-bits of the r value are zero and >> truncated) so the r-value is only 21 bytes long! A publicly known k leaks >> the signing key, but that doesn't matter for our purposes. >> >> Using this k, we can ensure that the r values on two signatures are the >> same by inspecting their length using `OP_SIZE(sig) < (21+32+6)`. Grinding >> r to find a smaller value requires 2^96 (12 bytes of zeros) computations >> assuming no mathematical shortcut such as the one used to find k=1/2. >> >> >> To explain how to use the above observative to sign Bitcoin transactions >> with Lamport signatures, let's remind ourselves how Lamport signatures [1] >> work. To sign 1-bit with a Lamport signature you first use a hash function >> H, to compute: x0 = H(y0), x1 = H(y1). Next, you publish x0,x1 as your >> public key. Then, to sign the bit 0, you release the value y0. Anyone can >> use y0 to verify that x0 == H(y0). To sign the bit 1, you release y1. >> >> We use Lamport signatures to sign the length of a bitcoin signature. The >> length of the signature serves as a proxy for the transaction hash of the >> spending transaction. Repeating this many times provides cryptographic >> levels of security. Let's look at an example: >> >> Alice computes her Lamport public keys and signing keys >> x00 = Hash(y00) >> x01 = Hash(y01) >> x10 = Hash(y10) >> x11 = Hash(y11) >> x20 = Hash(y20) >> x21 = Hash(y21) >> >> In pseudocode Alice's redeem script looks like: >> ``` >> PUSH ecdsaPubkey0 >> OP_CHECKSIG (ecdsaSig0) >> // Verify lamport signature on ecdsaSig0 >> PUSH x00, x01 >> if OP_SIZE (ecdsaSig0) == 59: >> if OP_HASH(y00) != x00: OP_RETURN >> else if OP_SIZE (ecdsaSig0) < 59: >> if OP_HASH(y01) != x01: OP_RETURN >> >> PUSH ecdsaPubkey1 >> OP_CHECKSIG (ecdsaSig1) >> // Verify lamport signature on ecdsaSig1 >> PUSH x10, x11 >> if OP_SIZE (ecdsaSig1) == 59: >> if OP_HASH(y10) != x10: OP_RETURN >> else if OP_SIZE (ecdsaSig1) < 59: >> if OP_HASH(y11) != x11: OP_RETURN >> >> // Verify lamport signature on ecdsaSig2 >> PUSH ecdsaPubkey2 >> OP_CHECKSIG (ecdsaSig2) >> // Verify lamport signature on ecdsaSig1 >> PUSH x20, x21 >> if OP_SIZE (ecdsaSig2) == 59: >> if OP_HASH(y20) != x10: OP_RETURN >> else if OP_SIZE (ecdsaSig2) < 59: >> if OP_HASH(y21) != x21: OP_RETURN >> ``` >> >> Alice computes the ECDSA signatures: ecdsaSig0, ecdsaSig1, ecdsaSig2. For >> example let’s say OP_SIZE(ecdsaSig0)=59, OP_SIZE(ecdsaSig1)=58, >> OP_SIZE(ecdsaSig2)=59. Thus, to spend she generates a Lamport signature >> over those lengths by releasing the preimages: y00, y11, y20. >> >> The spend script pseudocode: >> ``` >> PUSH ecdsaSig0 >> PUSH y00 // Signs that OP_SIZE(ecdsaSig0) should be 59 >> PUSH ecdsaSig1 >> PUSH y11 // Signs that OP_SIZE(ecdsaSig1) should be less than 59 >> PUSH ecdsaSig2 >> PUSH y20 // Signs that OP_SIZE(ecdsaSig2) should be 59 >> ``` >> >> The advantage Alice has over an attacker attempting to steal her funds is >> that all Alice has to do is release the preimages for the lengths of all of >> her ECDSA signatures, but an attacker has to construct a transaction hash >> that matches the size of her signatures for each different ECDSA signature. >> The probability an attacker manages this for three random ECDSA signatures >> given the lengths above (59,58,59) is 255/256 * 1/256 * 255/256 ~= 0.3%. >> Alice can arbitrarily amplify her security by adding additional ECDSA >> signatures. >> >> It was pointed out to me by Andrew Poelstra that the probability that a >> random signature is shorter by one byte is 1/256 because OP_SIZE only >> measures the byte length of a value, not the bit length. This means most of >> the time if Alice just used three ECDSA signatures, they would all be >> length 59. In such a case the attacker would have (255/256)^3 = 98% >> probability of generating a transaction that can be spent using Alice's >> signature on the attacker's very first try! >> >> For this reason Alice really needs a lot of ECDSA signatures and probably >> also needs to grind for safer values to sign (safer = high diversity in >> length). >> >> Assuming a simplistic model of ECDSA signatures length Prob(1-1/256) for >> length 59 and Prob(1/256) for length <59, the probability that Alice will >> generate exactly m <59-length signatures and n-m 59 length signatures is: >> `(255/256)^(n-m)*(1/256)^m*(n choose m)`. >> >> An attacker would need to not only generate m <59-length signatures and >> n-m 59 length signatures, but generate them in the same position as Alice >> generated them. The probability an attacker will generate exactly m >> <59-length signatures and n-m 59 length signatures in the same position as >> Alice is: (255/256)^(n-m)*(1/256)^m >> >> On average Alice would need 1000 attempts to sign with n=800,m=10. >> Whereas an attacker would need to make 2^84 attempts to brute force the >> output after seeing alice attempt to spend that output using a n=800,m=10 >> signature. >> >> ## Known weaknesses >> >> 1. *The Tuning Attack:* The attacker can use different SIG_HASH flags per >> signature to attack each signature individually. For instance ecdsaSig1 >> doesn't have the right length, the attacker can try SIGHASH_NONE to try >> again without changing any of the other signature lengths. This provides >> the attacker some advantage but with sufficient numbers of signatures it >> does not break the scheme. Alice can also use this approach to increase the >> security of her signatures by increasing length diversity. Unclear if this >> helps or hurts security more. >> >> 2. *Mix and Match Attack:* Even if an attacker can not grind a shorter >> r-value, an r-value of roughly 21-23 bytes would allow an attacker to make >> a few more individual attempts on a particular signature length. This is >> because we only measure the total length of the ECDSA signature, so a >> 23-byte r-value combined with a 29-byte s-value would be 23+29+6 = 58 >> bytes. 29-byte s-value are rare and occur with ~1/2^24 probability, but if >> an attacker managed to grind a 23-byte r-value at a cost of 2^72 >> computations, it would provide the attacker some advantage. >> >> ## Known Improvements >> >> 1. Rather than only signing if the length is 59 or less. We could extend >> the scheme to sign multiple ECDSA signature length values, 59, 58, 57, >> 56... This could enable Alice to greatly increase her security as say 56 >> would only occur 1 out of every 2^32 signatures. Winternitz One Time >> signatures (WOTs) [2] could be used here to compress signature length. >> >> 1. Jeremy Rubun suggested the following optimization: rather than >> directly signing the ECDSA signatures lengths, you construct a 32-bit bit >> vector of the signature lengths using OP_MUL, OP_ADD. >> >> bit vector = OP_SIZE(ecdsaSig0)==59 + 2*(OP_SIZE(ecdsaSig1)==59) + >> 4*(OP_SIZE(ecdsaSig2)==59) ... >> >> Then you compute a Winternitz One Time signature over this bit vector. >> This would require also computing a WInternitz or Lamport signature over a >> checksum of the bit vector. This would substantially reduce the number of >> lamport public keys and signing keys and likely reduce the size of redeem >> script and spend script by half. >> >> 3. Since 59 is the default length, Alice does not in fact need to sign >> 59. It could be inferred that if no preimage is given or say the preimage 0 >> is given, the length that Alice intends is 59. This would save space on the >> spend script and redeem script. >> >> >> ## Open Questions >> >> 1. Could OP_CODESEPARATOR be used by Alice or the attacker to either >> strengthen or weaken the security of this scheme. Alice using >> OP_CODESEPARATOR to strengthen the security of this scheme by increasing >> signature length diversity was suggested by Jeremy Rubin. After some >> discussion, the fact that the redeem script is part of the P2SH address >> means that the data in OP_CODESEPARATOR would still influence all the other >> ECDSA signatures. That said, perhaps there is some way it can be exploited >> to either help Alice or help the attacker. >> >> 2. If a nonce value k was discovered such that k*G = r = 1, we could >> remove the assumption that no could find a smaller r. It is unknown how to >> find r=1 as it requires finding the discrete log. It is possible to create >> transaction signatures that have r=1 without knowing k, through the use of >> ECDSA pubkey recovery. This does not work for our scheme as we must commit >> to the ECDSA public key in the spent transaction. Are there any known >> smaller r values than r=1/2*G? >> >> 3. How many bits of security does each ECDSA signature contribute in this >> scheme given the SIGHASH mix and match attack above? How many ECDSA >> signatures are needed? We have modeled ECDSA s-values signatures being >> uniformly drawn from 2^256. It seems unlikely to me that the Elliptic Curve >> math lines up perfectly with a 256 bit space especially for a fixed r-value >> that has special mathematical properties. Non-uniformity here could end up >> helping (increasing length diversity) or hurting (a pattern an attacker >> could exploit to match the length faster than brute force) the security. >> >> 4. An attacker could trade off brute forcing the transaction hash lengths >> by computing a small r-value. What does the time-memory trade look like >> here? >> >> 5. Is there any use for this beyond a fun party trick? >> >> Thanks to Madars Virza, Dan Gould, Armin Sabouri, Neha Narula, Jeremy >> Rubin, Andrew Poelstra, Robin Linus for discussing this with me and giving >> me feedback. This initial discuss was fueled by the MIT DCI espresso >> machine. I've attempted to credit all ideas contributed to the contributor, >> if I got this wrong or missed a contribution shoot me an email. Any >> mistakes are my own as I wrote this up. >> >> [0]: "Bitcoin Wallet Recovery via ECDSA Short Signatures" >> https://github.com/demining/Bitcoin-Wallet-Recovery?tab=readme-ov-file >> >> [1]: "Constructing Digital Signatures from a One Way Function", Leslie >> Lamport (1979), >> https://www.microsoft.com/en-us/research/publication/constructing-digital-signatures-one-way-function/ >> >> [2]: "A Certified Digital Signature", Ralph C. Merkle (1979), >> https://www.ralphmerkle.com/papers/Certified1979.pdf >> >> [3]: "Timelocked Proof of Work via signature length", Robin Linus >> (2021), >> https://gist.github.com/RobinLinus/95de641ed1e3d9fde83bdcf5ac289ce9#file-sig_pow-md >> >> [4]: "Proof of Work in Bitcoin Script", Robin Linus (2020), >> https://github.com/coins/bitcoin-scripts/blob/master/proof-of-work.md >> >> [5]: "sig-pow - work-locked outputs", VzxPLnHqr (2022), >> https://github.com/VzxPLnHqr/sig-pow/ >> >> [6]: "[Lightning-dev] Better privacy with SNARKs", Anthony Towns (2015), >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html >> >> [7]: "Quantum Proofing Bitcoin with a CAT", Jeremy Rubin (2021), >> https://rubin.io/blog/2021/07/06/quantum-bitcoin/ >> >> [8]: "CheckSigFromStack for 5 Byte Values", Jeremy Rubin (2021), >> https://rubin.io/blog/2021/07/02/signing-5-bytes/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BXyW8wNOekw13C5jDMzQ-dOJpQrBC%2BqR8-uDot25tM%3DXA%40mail.gmail.com >> <https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BXyW8wNOekw13C5jDMzQ-dOJpQrBC%2BqR8-uDot25tM%3DXA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BW9x70K-nSW1FvKyK%2BjYn2LnzPR8cRGxPJ4tpKsBzT8fA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 18113 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-04-30 12:32 ` Matthew Zipkin 2024-04-30 13:25 ` Ethan Heilman@ 2024-04-30 14:21 ` Andrew Poelstra2024-04-30 20:43 ` Ethan Heilman ` (2 more replies) 1 sibling, 3 replies; 18+ messages in thread From: Andrew Poelstra @ 2024-04-30 14:21 UTC (permalink / raw) To: Matthew Zipkin;+Cc:Ethan Heilman, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 1753 bytes --] On Tue, Apr 30, 2024 at 08:32:42AM -0400, Matthew Zipkin wrote: > > if an attacker managed to grind a 23-byte r-value at a cost of 2^72 > computations, it would provide the attacker some advantage. > > If we are assuming discrete log is still hard, why do we need Lamport > signatures at all? In a post-quantum world, finding k such that r is 21 > bytes or less is efficient for the attacker. > Aside from Ethan's point that a variant of this technique is still secure in the case that discrete log is totally broken (or even partially broken...all we need is that _somebody_ is able to find the discrete log of the x=1 point and for them to publish this). Another reason this is useful is that if you have a Lamport signature on the stack which is composed of SIZE values, all of which are small enough to be manipulated with the numeric script opcodes, then you can do covenants in Script. (Sadly(?), I think none of this works in the context of the 201-opcode limit...and absent BitVM challenge-response tricks it's unlikely you can do much in the context of the 4MWu block size limit..), but IMO it's a pretty big deal that size limits are now the only reason that Bitcoin doesn't have covenants.) -- Andrew Poelstra Director, Blockstream Research Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZjD-dMMGxoGNgzIg%40camus. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-04-30 14:21 ` Andrew Poelstra@ 2024-04-30 20:43 ` Ethan Heilman2024-05-01 3:46 ` Antoine Riard 2024-05-06 7:39 ` David A. Harding 2024-05-09 0:31 ` Ben Carman 2 siblings, 1 reply; 18+ messages in thread From: Ethan Heilman @ 2024-04-30 20:43 UTC (permalink / raw) To: Andrew Poelstra;+Cc:Matthew Zipkin, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 3670 bytes --] One could redesign this scheme to minimize the number of opcodes. Back of the napkin scheme follows: Alice, rather than Lamport signing the length of each ECDSA signature, instead Lamport (or WOTS) signs a vector of the positions of the low-length ECDSA signatures (low length here means length=58 rather than length=59). Then the redeem script would only check the length of those particular signatures and could drop the other other public keys. This saves significantly on the number of opcodes because we only need to check the Lamport signature on the vector, no one each signature length and we can drop unused checked signatures without evaluating them. Alice's advantage over the attacker is that she gets to fix the positions of the low length ECDSA signatures after she generates them. This means if the total number of signatures is N and the number of low length signatures is M, her advantage over the attacker is (N choose M). For instance if N=M=10, to generate 10 59-length signatures, Alice needs to perform 2^(8*10) work. This is because we assume the probability of generating a 58-byte ECDSA signature is 1/256 (1/2^8). However if N=40, M=10 she only needs to perform 2^(8*10)/(40 choose 10) work. If we assume that we want 80 bits of security, this means we need M=10 low length ECDCSA signatures (2^(8*10)). The next parameter is how cheap we want this to be for Alice to compute, we can boost Alice's signing time by increasing N and remove log2(N choose 10) from the work she needs to compute the signature. If we want to ensure Alice has to do no more than 2^32 work to sign, then we need N=46 or 46 ecdsa signatures. On Tue, Apr 30, 2024 at 10:21 AM Andrew Poelstra <apoelstra@wpsoftware.net> wrote: > On Tue, Apr 30, 2024 at 08:32:42AM -0400, Matthew Zipkin wrote: > > > if an attacker managed to grind a 23-byte r-value at a cost of 2^72 > > computations, it would provide the attacker some advantage. > > > > If we are assuming discrete log is still hard, why do we need Lamport > > signatures at all? In a post-quantum world, finding k such that r is 21 > > bytes or less is efficient for the attacker. > > > > Aside from Ethan's point that a variant of this technique is still > secure in the case that discrete log is totally broken (or even > partially broken...all we need is that _somebody_ is able to find the > discrete log of the x=1 point and for them to publish this). > > Another reason this is useful is that if you have a Lamport signature on > the stack which is composed of SIZE values, all of which are small > enough to be manipulated with the numeric script opcodes, then you can > do covenants in Script. > > (Sadly(?), I think none of this works in the context of the 201-opcode > limit...and absent BitVM challenge-response tricks it's unlikely you can > do much in the context of the 4MWu block size limit..), but IMO it's a > pretty big deal that size limits are now the only reason that Bitcoin > doesn't have covenants.) > > -- > Andrew Poelstra > Director, Blockstream Research > Email: apoelstra at wpsoftware.net > Web: https://www.wpsoftware.net/andrew > > The sun is always shining in space > -Justin Lewis-Webster > > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BUnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGfjw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 4500 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-04-30 20:43 ` Ethan Heilman@ 2024-05-01 3:46 ` Antoine Riard2024-05-01 20:02 ` Ethan Heilman 0 siblings, 1 reply; 18+ messages in thread From: Antoine Riard @ 2024-05-01 3:46 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 6527 bytes --] Hi Ethan, From my understanding, you're proposing to emulate Lamport signature verification / generation scheme by leveraging the implicit signature digest of the OP_CHECKSIG operation, which has been a valid Bitcoin Script opcode since genesis block. Signature digests is a commitment to a bitcoin transaction fields, and this is verified by the interpreter both for ECDSA and Schnorr schemes. Here you're proposing to use the ECDSA's `k` nonce as a fixed public value by committing the ECDSA-signature length as a parameter of an OP_SIZE and the cleartext `r,s` signature itself as the verification parameter of a OP_SHA256, emulating the h(x) = y for Lamport signature range of bits, all in a redeem script (i.e P2SH). I don't know if your proposed scheme is secure against message forgery attacks or invalid curve domain parameters, e.g using the point at infinity as your point R, and if from them you could play tricks with coordinates. On the usage of such emulated Lamport signature scheme in a public transaction-relay network, there is one fundamental security property of Lamport signature to be aware off, mainly the one-time usage. So this is very unclear if as soon you're broadcasting the transaction, miners coalition could withhold the transaction inclusion to trigger the initial signer to reveal more a lot of pre-committed fixed-nonce ECDSA signatures. Apart of concerns of this scheme in a blockchain and assuming it's not utterly broken due to message forgery attacks, I'm skeptical on the robustness of the scheme as the number of on-chain pre-committed signatures is a parameter of the preimage-resistance of the Lamport signature scheme itself. Sounds a classic time-space tradeoff, by increasing the lot of fixed-nonce signatures we're making it harder to break, even for observers with significant computational ressources. Beyond, 2^64 bit of security doesn't seem a lot in considerations of state-of-the-art collision attacks on hash functions from recent academic literature. And one have to consider how you can take the short-cut by pre-computing rainbow tables for ECDSA r-value of a given signature size. I think a more interesting open question of this post is if we have already hash-chain-based covenant "today" in Bitcoin. If by fixing the integer `z` of the s-value of ECDSA signature in redeem script, and computing backward the chain of chids redeem scripts to avoid hash-chain dependencies. This is unclear what would be the security guarantees and average btc units cost for scriptSig / witness under current block size limit of 4MWU. Best, Antoine Le mardi 30 avril 2024 à 22:18:36 UTC+1, Ethan Heilman a écrit : > One could redesign this scheme to minimize the number of opcodes. > > Back of the napkin scheme follows: > > Alice, rather than Lamport signing the length of each ECDSA signature, > instead Lamport (or WOTS) signs a vector of the positions of the low-length > ECDSA signatures (low length here means length=58 rather than length=59). > Then the redeem script would only check the length of those particular > signatures and could drop the other other public keys. This saves > significantly on the number of opcodes because we only need to check the > Lamport signature on the vector, no one each signature length and we can > drop unused checked signatures without evaluating them. > > Alice's advantage over the attacker is that she gets to fix the positions > of the low length ECDSA signatures after she generates them. This means if > the total number of signatures is N and the number of low length signatures > is M, her advantage over the attacker is (N choose M). For instance if > N=M=10, to generate 10 59-length signatures, Alice needs to perform > 2^(8*10) work. This is because we assume the probability of generating a > 58-byte ECDSA signature is 1/256 (1/2^8). However if N=40, M=10 she only > needs to perform 2^(8*10)/(40 choose 10) work. > > If we assume that we want 80 bits of security, this means we need M=10 low > length ECDCSA signatures (2^(8*10)). The next parameter is how cheap we > want this to be for Alice to compute, we can boost Alice's signing time by > increasing N and remove log2(N choose 10) from the work she needs to > compute the signature. If we want to ensure Alice has to do no more than > 2^32 work to sign, then we need N=46 or 46 ecdsa signatures. > > On Tue, Apr 30, 2024 at 10:21 AM Andrew Poelstra <apoe...@wpsoftware.net> > wrote: > >> On Tue, Apr 30, 2024 at 08:32:42AM -0400, Matthew Zipkin wrote: >> > > if an attacker managed to grind a 23-byte r-value at a cost of 2^72 >> > computations, it would provide the attacker some advantage. >> > >> > If we are assuming discrete log is still hard, why do we need Lamport >> > signatures at all? In a post-quantum world, finding k such that r is 21 >> > bytes or less is efficient for the attacker. >> > >> >> Aside from Ethan's point that a variant of this technique is still >> secure in the case that discrete log is totally broken (or even >> partially broken...all we need is that _somebody_ is able to find the >> discrete log of the x=1 point and for them to publish this). >> >> Another reason this is useful is that if you have a Lamport signature on >> the stack which is composed of SIZE values, all of which are small >> enough to be manipulated with the numeric script opcodes, then you can >> do covenants in Script. >> >> (Sadly(?), I think none of this works in the context of the 201-opcode >> limit...and absent BitVM challenge-response tricks it's unlikely you can >> do much in the context of the 4MWu block size limit..), but IMO it's a >> pretty big deal that size limits are now the only reason that Bitcoin >> doesn't have covenants.) >> >> -- >> Andrew Poelstra >> Director, Blockstream Research >> Email: apoelstra at wpsoftware.net >> Web: https://www.wpsoftware.net/andrew >> >> The sun is always shining in space >> -Justin Lewis-Webster >> >> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 8140 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-05-01 3:46 ` Antoine Riard@ 2024-05-01 20:02 ` Ethan Heilman0 siblings, 0 replies; 18+ messages in thread From: Ethan Heilman @ 2024-05-01 20:02 UTC (permalink / raw) To: Antoine Riard;+Cc:Bitcoin Development Mailing List Hi Antoine, > On the usage of such emulated Lamport signature scheme in a public transaction-relay network, there is one fundamental security property of Lamport signature to be aware off, mainly the one-time usage. So this is very unclear if as soon you're broadcasting the transaction, miners coalition could withhold the transaction inclusion to trigger the initial signer to reveal more a lot of pre-committed fixed-nonce ECDSA signatures. I'm not sure I understand what you are saying here. I agree that once Alice broadcasts a transaction spending such an output, she can not double spend that output without losing security. You'd want to define the unforgeability property to be EU-CMA with only a single signature. Why would Alice simply just not rebroadcast her original transaction? If she wants the capability to bump the fees without changing the sig hash, she can use the SIGHASH flag anyone can pay or CPFP. > using the point at infinity as your point R, and if from them you could play tricks with coordinates. What do you mean by this? k=0? I do agree that this scheme is making some very odd assumptions about ecdsa signatures and they may not hold. Certainly no one should expect this scheme to be secure without a proof of security or at the least some sort of justification for why anyone expects these assumptions to hold. > Beyond, 2^64 bit of security doesn't seem a lot in considerations of state-of-the-art collision attacks on hash functions from recent academic literature. I agree that 64 bits of security is nowhere near safe. I used 80 bits of security in the example because that is the collision resistance of P2SH. 80-bits is still probably too low. > And one have to consider how you can take the short-cut by pre-computing rainbow tables for ECDSA r-value of a given signature size. It's worse than that! Storage and lookup would not require anything so fancy as rainbow tables. Once you have precomputed a 20 byte r-value you can use it everywhere. Grinding such an r-value would cost 2^96 queries for 50% success rate, but would let you trivially break any of these signatures which used a 21 byte r-value with a pen and some paper. Still, if you could do 2^96 ecdsa queries, it would be computationally expensive as mining 1,125,899,906,842,620 bitcoin blocks. You'd probably be better off mining those blocks than grinding the r-value. On Wed, May 1, 2024 at 4:57 AM Antoine Riard <antoine.riard@gmail.com> wrote: > > Hi Ethan, > > From my understanding, you're proposing to emulate Lamport signature verification / generation > scheme by leveraging the implicit signature digest of the OP_CHECKSIG operation, which has been > a valid Bitcoin Script opcode since genesis block. Signature digests is a commitment to a bitcoin > transaction fields, and this is verified by the interpreter both for ECDSA and Schnorr schemes. > > Here you're proposing to use the ECDSA's `k` nonce as a fixed public value by committing the > ECDSA-signature length as a parameter of an OP_SIZE and the cleartext `r,s` signature itself as > the verification parameter of a OP_SHA256, emulating the h(x) = y for Lamport signature range of > bits, all in a redeem script (i.e P2SH). > > I don't know if your proposed scheme is secure against message forgery attacks or invalid curve > domain parameters, e.g using the point at infinity as your point R, and if from them you could play > tricks with coordinates. > > On the usage of such emulated Lamport signature scheme in a public transaction-relay network, > there is one fundamental security property of Lamport signature to be aware off, mainly the one-time > usage. So this is very unclear if as soon you're broadcasting the transaction, miners coalition could > withhold the transaction inclusion to trigger the initial signer to reveal more a lot of pre-committed > fixed-nonce ECDSA signatures. > > Apart of concerns of this scheme in a blockchain and assuming it's not utterly broken due to > message forgery attacks, I'm skeptical on the robustness of the scheme as the number of on-chain > pre-committed signatures is a parameter of the preimage-resistance of the Lamport signature scheme > itself. Sounds a classic time-space tradeoff, by increasing the lot of fixed-nonce signatures we're making > it harder to break, even for observers with significant computational ressources. > > Beyond, 2^64 bit of security doesn't seem a lot in considerations of state-of-the-art collision attacks > on hash functions from recent academic literature. And one have to consider how you can take the > short-cut by pre-computing rainbow tables for ECDSA r-value of a given signature size. > > I think a more interesting open question of this post is if we have already hash-chain-based covenant > "today" in Bitcoin. If by fixing the integer `z` of the s-value of ECDSA signature in redeem script, and > computing backward the chain of chids redeem scripts to avoid hash-chain dependencies. This is unclear > what would be the security guarantees and average btc units cost for scriptSig / witness under current block > size limit of 4MWU. > > Best, > Antoine > Le mardi 30 avril 2024 à 22:18:36 UTC+1, Ethan Heilman a écrit : >> >> One could redesign this scheme to minimize the number of opcodes. >> >> Back of the napkin scheme follows: >> >> Alice, rather than Lamport signing the length of each ECDSA signature, instead Lamport (or WOTS) signs a vector of the positions of the low-length ECDSA signatures (low length here means length=58 rather than length=59). Then the redeem script would only check the length of those particular signatures and could drop the other other public keys. This saves significantly on the number of opcodes because we only need to check the Lamport signature on the vector, no one each signature length and we can drop unused checked signatures without evaluating them. >> >> Alice's advantage over the attacker is that she gets to fix the positions of the low length ECDSA signatures after she generates them. This means if the total number of signatures is N and the number of low length signatures is M, her advantage over the attacker is (N choose M). For instance if N=M=10, to generate 10 59-length signatures, Alice needs to perform 2^(8*10) work. This is because we assume the probability of generating a 58-byte ECDSA signature is 1/256 (1/2^8). However if N=40, M=10 she only needs to perform 2^(8*10)/(40 choose 10) work. >> >> If we assume that we want 80 bits of security, this means we need M=10 low length ECDCSA signatures (2^(8*10)). The next parameter is how cheap we want this to be for Alice to compute, we can boost Alice's signing time by increasing N and remove log2(N choose 10) from the work she needs to compute the signature. If we want to ensure Alice has to do no more than 2^32 work to sign, then we need N=46 or 46 ecdsa signatures. >> >> On Tue, Apr 30, 2024 at 10:21 AM Andrew Poelstra <apoe...@wpsoftware.net> wrote: >>> >>> On Tue, Apr 30, 2024 at 08:32:42AM -0400, Matthew Zipkin wrote: >>> > > if an attacker managed to grind a 23-byte r-value at a cost of 2^72 >>> > computations, it would provide the attacker some advantage. >>> > >>> > If we are assuming discrete log is still hard, why do we need Lamport >>> > signatures at all? In a post-quantum world, finding k such that r is 21 >>> > bytes or less is efficient for the attacker. >>> > >>> >>> Aside from Ethan's point that a variant of this technique is still >>> secure in the case that discrete log is totally broken (or even >>> partially broken...all we need is that _somebody_ is able to find the >>> discrete log of the x=1 point and for them to publish this). >>> >>> Another reason this is useful is that if you have a Lamport signature on >>> the stack which is composed of SIZE values, all of which are small >>> enough to be manipulated with the numeric script opcodes, then you can >>> do covenants in Script. >>> >>> (Sadly(?), I think none of this works in the context of the 201-opcode >>> limit...and absent BitVM challenge-response tricks it's unlikely you can >>> do much in the context of the 4MWu block size limit..), but IMO it's a >>> pretty big deal that size limits are now the only reason that Bitcoin >>> doesn't have covenants.) >>> >>> -- >>> Andrew Poelstra >>> Director, Blockstream Research >>> Email: apoelstra at wpsoftware.net >>> Web: https://www.wpsoftware.net/andrew >>> >>> The sun is always shining in space >>> -Justin Lewis-Webster >>> > -- > You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BXjPwsst%3DrU5KS%3D%3DF8VfXaLtcfgoWt2CuY%2BhBMmLXhCsA%40mail.gmail.com. ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-04-30 14:21 ` Andrew Poelstra 2024-04-30 20:43 ` Ethan Heilman@ 2024-05-06 7:39 ` David A. Harding2024-05-06 16:48 ` Andrew Poelstra 2024-05-09 0:31 ` Ben Carman 2 siblings, 1 reply; 18+ messages in thread From: David A. Harding @ 2024-05-06 7:39 UTC (permalink / raw) To: Andrew Poelstra Cc: Matthew Zipkin, Ethan Heilman, Bitcoin Development Mailing List On 2024-04-30 04:21, Andrew Poelstra wrote: > Another reason this is useful is that if you have a Lamport signature > on > the stack which is composed of SIZE values, all of which are small > enough to be manipulated with the numeric script opcodes, then you can > do covenants in Script. Hi Andrew, I don't understand the above. I think of a covenant as a script that is able to restrict the scriptPubKey of the transaction that spends it. As I understand Heilman's description, a lamport signature commits to the size of an ECDSA signature (which can naturally vary) and the ECDSA signature commits to the spending transaction. Performing the lamport verification on the stack is practically equivalent to OP_CHECKSIGFROMSTACK, which is half of what you need for a covenant. As you've previously described[1], the other half is some method for introspection. How do lamport signatures offer introspection when they're restricted to committing to ECDSA signatures that can't be known at the time a script is created due to circular dependency in hashing (i.e., the ECDSA signature commits to the spending transaction, which commits to the previous transaction's txid, which commits to the script)? Thanks!, -Dave [1] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/47711dc4ffe9d661e8321b05b6adab4e%40dtrt.org. ^ permalink raw reply [flat|nested] 18+ messages in thread

*2024-05-06 7:39 ` David A. HardingRe: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)@ 2024-05-06 16:48 ` Andrew Poelstra2024-05-06 18:56 ` David A. Harding 0 siblings, 1 reply; 18+ messages in thread From: Andrew Poelstra @ 2024-05-06 16:48 UTC (permalink / raw) To: David A. Harding Cc: Matthew Zipkin, Ethan Heilman, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 2444 bytes --] On Sun, May 05, 2024 at 09:39:51PM -1000, David A. Harding wrote: > > Hi Andrew, > > I don't understand the above. I think of a covenant as a script that is > able to restrict the scriptPubKey of the transaction that spends it. As I > understand Heilman's description, a lamport signature commits to the size of > an ECDSA signature (which can naturally vary) and the ECDSA signature > commits to the spending transaction. Performing the lamport verification on > the stack is practically equivalent to OP_CHECKSIGFROMSTACK, which is half > of what you need for a covenant. As you've previously described[1], the > other half is some method for introspection. How do lamport signatures > offer introspection when they're restricted to committing to ECDSA > signatures that can't be known at the time a script is created due to > circular dependency in hashing (i.e., the ECDSA signature commits to the > spending transaction, which commits to the previous transaction's txid, > which commits to the script)? > Aside from limits on transaction size, post-Taproot script can verify a trace of any program execution, as long as the individual elements it is operating on fit into 4-byte CScriptNums. You can therefore implement SHA2, ECDSA, etc., and reconstruct the pattern of SIZE elements by feeding in transaction data. Which of course can then be arbitrarily constrained. Probably actually doing this would take more than 4 megs of script and you would need to use some sort of BitVM tricks and the whole thing might not work. But this was my point in saying that "only the script limits are stopping us from having covenants". And pre-Taproot we have only 201 opcodes so of course this is all totally out of the question :) but plausibly we could make a copy of the Lamport signature in a Taproot output and then use non-equivocation slashing conditions to somehow make things work. -- Andrew Poelstra Director, Blockstream Research Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZjkJ0fPyzuAPTLWS%40camus. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-05-06 16:48 ` Andrew Poelstra@ 2024-05-06 18:56 ` David A. Harding2024-05-06 19:06 ` Andrew Poelstra 0 siblings, 1 reply; 18+ messages in thread From: David A. Harding @ 2024-05-06 18:56 UTC (permalink / raw) To: Andrew Poelstra Cc: Matthew Zipkin, Ethan Heilman, Bitcoin Development Mailing List On 2024-05-06 06:48, Andrew Poelstra wrote: > [...] post-Taproot script can verify a > trace of any program execution, as long as the individual elements it > is > operating on fit into 4-byte CScriptNums. You can therefore implement > SHA2, ECDSA, etc., and reconstruct the pattern of SIZE elements by > feeding in transaction data. Which of course can then be arbitrarily > constrained. Thanks for your answer! I think I understand. However, we don't have ECDSA in tapscript; all signatures in tapscript are 64 bytes plus an optional sighash byte, so there's no natural variation in signature size. -Dave -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/a5a86fcd50e2cdbdf40a12ac9463a828%40dtrt.org. ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-05-06 18:56 ` David A. Harding@ 2024-05-06 19:06 ` Andrew Poelstra2024-05-07 0:55 ` Antoine Riard 2024-05-07 4:11 ` David A. Harding 0 siblings, 2 replies; 18+ messages in thread From: Andrew Poelstra @ 2024-05-06 19:06 UTC (permalink / raw) To: David A. Harding Cc: Matthew Zipkin, Ethan Heilman, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 1303 bytes --] On Mon, May 06, 2024 at 08:56:21AM -1000, David A. Harding wrote: > On 2024-05-06 06:48, Andrew Poelstra wrote: > > [...] post-Taproot script can verify a > > trace of any program execution, as long as the individual elements it is > > operating on fit into 4-byte CScriptNums. You can therefore implement > > SHA2, ECDSA, etc., and reconstruct the pattern of SIZE elements by > > feeding in transaction data. Which of course can then be arbitrarily > > constrained. > > Thanks for your answer! I think I understand. However, we don't have ECDSA > in tapscript; all signatures in tapscript are 64 bytes plus an optional > sighash byte, so there's no natural variation in signature size. > You can implement ECDSA. It will just take a *lot* of opcodes. -- Andrew Poelstra Director, Blockstream Research Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZjkqIzPSFLc0GJJ1%40camus. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-05-06 19:06 ` Andrew Poelstra@ 2024-05-07 0:55 ` Antoine Riard2024-05-07 16:05 ` Ethan Heilman 2024-05-07 4:11 ` David A. Harding 1 sibling, 1 reply; 18+ messages in thread From: Antoine Riard @ 2024-05-07 0:55 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 6410 bytes --] Hi Ethan, > I'm not sure I understand what you are saying here. I agree that once > Alice broadcasts a transaction spending such an output, she can not > double spend that output without losing security. You'd want to define > the unforgeability property to be EU-CMA with only a single signature. > Why would Alice simply just not rebroadcast her original transaction? > If she wants the capability to bump the fees without changing the sig > hash, she can use the SIGHASH flag anyone can pay or CPFP. If my understanding of your scheme is correct, the Lamport public key (e.g x00 == Hash(y00) is committed in the redeem script of a said UTXO. scriptpubkey. I think this opens the following denial-of-service attack by adversaries with hashrate capabilities: - Alice Lamport-emulated signs and broadcast her transaction X - Coalition of Miners (e.g 30% of network) refuse to include Alice's transaction X - Alice can: - a) wait for the 70% honest network to mine her transaction - b) increase her feerate to bump incentives to mine transaction X - If Alice picks up option b) - Alice Lamport-emulated signs and broadcast her transaction X by using ACP flag / CPFP - This assumes the consumption of a "fresh" fee-bumping UTXO - This fee-bumping UTXO can be locked under a Lamport emulated-pubkey I think this scheme with a one-time usage property is more exposed to denial-of-service attacks (or wallet UTXO deanonymization) than ECDSA / Schnorr scheme. I believe you might even have a worst-case scenario of this DoS where a coalition of mining attackers force you to one-time sig all your Lamport pubkeys committed in UTXOs (original UTXO + fee-bumping UTXOs), in a way that the orignal UTXO cannot be moved because its feerate is perpetually under mempool min fee, or the marginal ancestor feerate unit of miners block templates. I don't know if this vector of attack is correct, however one can note it could arise in alternative spontaneous scenarios, such as second-layers scarce liquidity allocation (e.g dual-funding), where many UTXOs concurrent spends might compete to confirm first. > What do you mean by this? k=0? I do agree that this scheme is making > some very odd assumptions about ecdsa signatures and they may not > hold. Certainly no one should expect this scheme to be secure without > a proof of security or at the least some sort of justification for why > anyone expects these assumptions to hold. I think the ECDSA signature verification algorithm forbids the usage of the point at infinity for the curve point resulting from the modular arithmetic on your r-value and s-value, not k=0 where k is the nonce. I don't know if you could play with the transaction hash to produce a curve point which is equals to the point at infinity, especially in context where the transaction hash is including inputs from multiple non-trusted counterparties (e.g if you're using SIGHASH flags). > It's worse than that! Storage and lookup would not require anything so > fancy as rainbow tables. Once you have precomputed a 20 byte r-value > you can use it everywhere. Grinding such an r-value would cost 2^96 > queries for 50% success rate, but would let you trivially break any of > these signatures which used a 21 byte r-value with a pen and some > paper. Still, if you could do 2^96 ecdsa queries, it would be > computationally expensive as mining 1,125,899,906,842,620 bitcoin > blocks. You'd probably be better off mining those blocks than grinding > the r-value. Well, we're not comparing "apple-to-apple" here as on one side you have modular arithmetic operations, on the other side bitwise rotations. I'm thinking you might have an advantage in your ecdsa queries as a finite field is, as the name say so, "finite" so you could theoretically pre-compute all entries in your storage. On the other hand, with block mining (even assuming a functional implementation of Grover's algorithm) you have lookup and propagation latency under 10 min in average. Sounds you can parellize both problems resolution (re-use hash round states or point addition), so it might be just a classicla time-space trade-off here. > I think a more interesting open question of this post is if we have already hash-chain-based covenant > "today" in Bitcoin. If by fixing the integer `z` of the s-value of ECDSA signature in redeem script, and > computing backward the chain of chids redeem scripts to avoid hash-chain dependencies. Correcting myself on my initial email, the design bottleneck here is obviously that spent outpoints are committed in a child signature digest in a no-APO world. This is still an interesting question if you can remove spent outpoints commitment by leveraging OP_SIZE or fixing other ECDSA signature components. Best, Antoine Le lundi 6 mai 2024 à 20:25:33 UTC+1, Andrew Poelstra a écrit : > On Mon, May 06, 2024 at 08:56:21AM -1000, David A. Harding wrote: > > On 2024-05-06 06:48, Andrew Poelstra wrote: > > > [...] post-Taproot script can verify a > > > trace of any program execution, as long as the individual elements it > is > > > operating on fit into 4-byte CScriptNums. You can therefore implement > > > SHA2, ECDSA, etc., and reconstruct the pattern of SIZE elements by > > > feeding in transaction data. Which of course can then be arbitrarily > > > constrained. > > > > Thanks for your answer! I think I understand. However, we don't have > ECDSA > > in tapscript; all signatures in tapscript are 64 bytes plus an optional > > sighash byte, so there's no natural variation in signature size. > > > > You can implement ECDSA. It will just take a *lot* of opcodes. > > -- > Andrew Poelstra > Director, Blockstream Research > Email: apoelstra at wpsoftware.net > Web: https://www.wpsoftware.net/andrew > > The sun is always shining in space > -Justin Lewis-Webster > > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/bd37a9f1-7fb9-4111-a069-31c3665073d2n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 7876 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-05-06 19:06 ` Andrew Poelstra 2024-05-07 0:55 ` Antoine Riard@ 2024-05-07 4:11 ` David A. Harding2024-05-07 14:34 ` Andrew Poelstra 1 sibling, 1 reply; 18+ messages in thread From: David A. Harding @ 2024-05-07 4:11 UTC (permalink / raw) To: Andrew Poelstra Cc: Matthew Zipkin, Ethan Heilman, Bitcoin Development Mailing List On 2024-05-06 09:06, Andrew Poelstra wrote: > You can implement ECDSA. It will just take a *lot* of opcodes. I'll accept that as a given, but how do you know that a given ECDSA signature actually commits to the transaction that contains it if OP_CHECKSIG only operates on fixed-size schnorr signatures? Is this what you're describing: if the controlling signature is a lamport signature that commits to an ECDSA signature, it's safe to disclose the private key for the ECDSA signature; when you don't have to worry about private key disclosure, it's safe to construct a schnorr signature that uses the same private key, nonce, and message commitment as the ECDSA signature; if that schnorr signature makes OP_CHECKSIG return true, then you know the message is the current transaction? That still leaves me confused. If ECDSA can be implemented within tapscript, then I would expect that schnorr could also be implemented within tapscript; that gives you an OP_CSFS equivalent. If being able to implement ECDSA in tapscript allows introspection, then I would expect implementing schnorr in tapscript would allow introspection; that gives you an OP_CAT equivalent. If you have OP_CSFS and OP_CAT, you have covenants and there's no need for lamport signatures or ECDSA. Apologies for my remaining confused in the face of something that's probably obvious, -Dave -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/93b8ed39b0aa3955eb9cb99f9fc5aae9%40dtrt.org. ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-05-07 4:11 ` David A. Harding@ 2024-05-07 14:34 ` Andrew Poelstra0 siblings, 0 replies; 18+ messages in thread From: Andrew Poelstra @ 2024-05-07 14:34 UTC (permalink / raw) To: David A. Harding Cc: Matthew Zipkin, Ethan Heilman, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 2954 bytes --] On Mon, May 06, 2024 at 06:11:48PM -1000, David A. Harding wrote: > On 2024-05-06 09:06, Andrew Poelstra wrote: > > You can implement ECDSA. It will just take a *lot* of opcodes. > > I'll accept that as a given, but how do you know that a given ECDSA > signature actually commits to the transaction that contains it if > OP_CHECKSIG only operates on fixed-size schnorr signatures? > You need to connect your Lamport signature to an ECDSA CHECKSIG (in a pre-Taproot output). So what I'm depending on here is that it's possible to "copy the signature" from a pre-Taproot spend to a post-Taproot spend by using Lamport signatures and some anti-equivocation scheme. In pre-Taproot we confirm that the signature matches the pattern of OP_SIZE outputs. In post-Taproot we reconstruct the signature and constrain the transaction, checking that it spends *both* the pre-Taproot and the post-Taproot output. > Is this what you're describing: if the controlling signature is a lamport > signature that commits to an ECDSA signature, it's safe to disclose the > private key for the ECDSA signature; when you don't have to worry about > private key disclosure, it's safe to construct a schnorr signature that uses > the same private key, nonce, and message commitment as the ECDSA signature; > if that schnorr signature makes OP_CHECKSIG return true, then you know the > message is the current transaction? > Nope, in this scheme we are avoiding Schnorr signatures entirely. > That still leaves me confused. If ECDSA can be implemented within > tapscript, then I would expect that schnorr could also be implemented within > tapscript; that gives you an OP_CSFS equivalent. If being able to implement > ECDSA in tapscript allows introspection, then I would expect implementing > schnorr in tapscript would allow introspection; that gives you an OP_CAT > equivalent. If you have OP_CSFS and OP_CAT, you have covenants and there's > no need for lamport signatures or ECDSA. > Implementing ECDSA in Tapscript *only* allows introspection in conjunction with the ability to force a user to spend a Tapscript output alongside a pre-Tapscript output containing the same ECDSA signature. And I am waving my hands and saying that I think you can force this by using covenant tricks. > Apologies for my remaining confused in the face of something that's probably > obvious, > Lol. This whole thing is kinda insane. -- Andrew Poelstra Director, Blockstream Research Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zjo72iTDYjwwsXW3%40camus. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-05-07 0:55 ` Antoine Riard@ 2024-05-07 16:05 ` Ethan Heilman0 siblings, 0 replies; 18+ messages in thread From: Ethan Heilman @ 2024-05-07 16:05 UTC (permalink / raw) To: Antoine Riard;+Cc:Bitcoin Development Mailing List Hi Antoine, Responding in line: > - Alice can: > - a) wait for the 70% honest network to mine her transaction > - b) increase her feerate to bump incentives to mine transaction X > - If Alice picks up option b) > - Alice Lamport-emulated signs and broadcast her transaction X by using ACP flag / CPFP > - This assumes the consumption of a "fresh" fee-bumping UTXO > - This fee-bumping UTXO can be locked under a Lamport emulated-pubkey > > I think this scheme with a one-time usage property is more exposed to denial-of-service > attacks (or wallet UTXO deanonymization) than ECDSA / Schnorr scheme. It sounded like originally you were saying she can't bump her fee without double signing, but as you point out ANYONECANPAY or CPFP let's you do fee bumping without double signing. This doesn't seem different from say a pre-signed bitcoin transaction that you can't change transaction hash of. > I think the ECDSA signature verification algorithm forbids the usage > of the point at infinity for the curve point resulting from the modular > arithmetic on your r-value and s-value, not k=0 where k is the nonce. > > I don't know if you could play with the transaction hash to produce > a curve point which is equals to the point at infinity, especially in > context where the transaction hash is including inputs from multiple > non-trusted counterparties (e.g if you're using SIGHASH flags). I don't see the attack. If the point at infinity is forbidden, how is this exploited? Wouldn't the attacker's signature just be rejected by the network? > Well, we're not comparing "apple-to-apple" here as on one side you have > modular arithmetic operations, on the other side bitwise rotations. I'm > thinking you might have an advantage in your ecdsa queries as a finite field > is, as the name say so, "finite" so you could theoretically pre-compute all > entries in your storage. On the other hand, with block mining (even assuming > a functional implementation of Grover's algorithm) you have lookup and > propagation latency under 10 min in average. Sounds you can parellize both > problems resolution (re-use hash round states or point addition), so it might > be just a classicla time-space trade-off here. If someone discovers a smaller r than used in the signatures, they would break the existing signatures I agree. Grover's might break P2SH in general so Bitcoin might be in real trouble at that point. > Correcting myself on my initial email, the design bottleneck here is obviously > that spent outpoints are committed in a child signature digest in a no-APO world. > This is still an interesting question if you can remove spent outpoints commitment > by leveraging OP_SIZE or fixing other ECDSA signature components. No APO? Thanks, Ethan -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BX-bhUuDxyYQ-MJGA49BgvnHW9-7L3zvBLPyJux%3DkqYbA%40mail.gmail.com. ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-04-30 14:21 ` Andrew Poelstra 2024-04-30 20:43 ` Ethan Heilman 2024-05-06 7:39 ` David A. Harding@ 2024-05-09 0:31 ` Ben Carman2024-05-09 12:46 ` Andrew Poelstra 2 siblings, 1 reply; 18+ messages in thread From: Ben Carman @ 2024-05-09 0:31 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2743 bytes --] I think it is possible to get past the 201 op code limit doing it in tapscript. I don't think it would have the same quantum security but could maybe be a path to covenants. My understanding is that you're using the OP_SIZE of the sig to basically decide to verify if the bit is a 0 or a 1, then do that verification. You could do the same trick with schnorr sigs, just for 0 bits don't include the sighash_all flag, and for 1 bits include it. This would allow you to get around all the resource limits that taproot lifted. This still should be safe since the the signature commits to if it is SIGHASH_DEFAULT vs SIGHASH_ALL. I am not sure if this will enable very complex things or just let you do it on 1 bit of information in tapscript. Best, benthecarman On Tuesday, April 30, 2024 at 9:22:54 AM UTC-5 Andrew Poelstra wrote: > On Tue, Apr 30, 2024 at 08:32:42AM -0400, Matthew Zipkin wrote: > > > if an attacker managed to grind a 23-byte r-value at a cost of 2^72 > > computations, it would provide the attacker some advantage. > > > > If we are assuming discrete log is still hard, why do we need Lamport > > signatures at all? In a post-quantum world, finding k such that r is 21 > > bytes or less is efficient for the attacker. > > > > Aside from Ethan's point that a variant of this technique is still > secure in the case that discrete log is totally broken (or even > partially broken...all we need is that _somebody_ is able to find the > discrete log of the x=1 point and for them to publish this). > > Another reason this is useful is that if you have a Lamport signature on > the stack which is composed of SIZE values, all of which are small > enough to be manipulated with the numeric script opcodes, then you can > do covenants in Script. > > (Sadly(?), I think none of this works in the context of the 201-opcode > limit...and absent BitVM challenge-response tricks it's unlikely you can > do much in the context of the 4MWu block size limit..), but IMO it's a > pretty big deal that size limits are now the only reason that Bitcoin > doesn't have covenants.) > > -- > Andrew Poelstra > Director, Blockstream Research > Email: apoelstra at wpsoftware.net > Web: https://www.wpsoftware.net/andrew > > The sun is always shining in space > -Justin Lewis-Webster > > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/b50b6b09-4d13-46ab-9776-f6b8a02aa2e0n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 3904 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-05-09 0:31 ` Ben Carman@ 2024-05-09 12:46 ` Andrew Poelstra2024-05-11 2:53 ` Antoine Riard 0 siblings, 1 reply; 18+ messages in thread From: Andrew Poelstra @ 2024-05-09 12:46 UTC (permalink / raw) To: Ben Carman;+Cc:Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 1548 bytes --] On Wed, May 08, 2024 at 05:31:18PM -0700, Ben Carman wrote: > I think it is possible to get past the 201 op code limit doing it in > tapscript. I don't think it would have the same quantum security but could > maybe be a path to covenants. My understanding is that you're using the > OP_SIZE of the sig to basically decide to verify if the bit is a 0 or a 1, > then do that verification. You could do the same trick with schnorr sigs, > just for 0 bits don't include the sighash_all flag, and for 1 bits include > it. This would allow you to get around all the resource limits that taproot > lifted. This still should be safe since the the signature commits to if it > is SIGHASH_DEFAULT vs SIGHASH_ALL. I am not sure if this will enable very > complex things or just let you do it on 1 bit of information in tapscript. > If I'm understanding you right, then what you're signing is your choice of sighash flags, rather than anything inherent to the transaction. So I don't think this works. -- Andrew Poelstra Director, Blockstream Research Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZjzFtus_aBchwKz2%40camus. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

*Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)2024-05-09 12:46 ` Andrew Poelstra@ 2024-05-11 2:53 ` Antoine Riard0 siblings, 0 replies; 18+ messages in thread From: Antoine Riard @ 2024-05-11 2:53 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 4221 bytes --] Hi Ethan, > It sounded like originally you were saying she can't bump her fee > without double signing, but as you point out ANYONECANPAY or CPFP > let's you do fee bumping without double signing. This doesn't seem > different from say a pre-signed bitcoin transaction that you can't > change transaction hash of. With lamport signature, the public key is committed in the coin. Once you're spending the coin, the secret key must be revealed to commit to the transaction hash. The secret key cannot be re-used to commit to another transaction hash and the spend *in its current state* must be included in the chain. With pre-signed bitcoin transaction under ecdsa / schnorr, the signer group can change the transaction hash (e.g adjust destination or feerate), assuming "off-chain" interactivity. > I don't see the attack. If the point at infinity is forbidden, how is > this exploited? Wouldn't the attacker's signature just be rejected by > the network? Yes, a pair of ecdsa (r, s) integers verifying as a point at infinity would be rejected by the network. Assume short r-value that can be guessed by the attacker, the k nonce is fixed and the attacker can contribute to the transaction hash. Can the attacker contributes to the transaction hash in way the pair of ecdsa (r, s) verifies as a point at infinity ? I don't think the attack works as the private key d is still assume to be secret here, and the computational space to find short-r and hash contribution inputs to provoke a point at infinity collision sounds to be huge. Though I cannot convince myself without a more fleshed scheme. > If someone discovers a smaller r than used in the signatures, they > would break the existing signatures I agree. Grover's might break P2SH > in general so Bitcoin might be in real trouble at that point. I still wonder if you could have tree of such lamport pubkeys, to have more sounds true lamport signature with a 1-to-1 bit mapping between transaction bit and lamport secret key bit ? Sounds you will hit consensus limits. And yeah note Grover's algo could also be used to break proof-of-work mining races, so trouble. > No APO? There is a "faux-ctv" variant I think known by a lot of people, where with bip118 anyprevout you can have no-input signature committed in the redeem script. A way to have ensure any spending child is a valid pre-image of the signature digest. Best, Antoine Le jeudi 9 mai 2024 à 13:49:04 UTC+1, Andrew Poelstra a écrit : > On Wed, May 08, 2024 at 05:31:18PM -0700, Ben Carman wrote: > > I think it is possible to get past the 201 op code limit doing it in > > tapscript. I don't think it would have the same quantum security but > could > > maybe be a path to covenants. My understanding is that you're using the > > OP_SIZE of the sig to basically decide to verify if the bit is a 0 or a > 1, > > then do that verification. You could do the same trick with schnorr > sigs, > > just for 0 bits don't include the sighash_all flag, and for 1 bits > include > > it. This would allow you to get around all the resource limits that > taproot > > lifted. This still should be safe since the the signature commits to if > it > > is SIGHASH_DEFAULT vs SIGHASH_ALL. I am not sure if this will enable > very > > complex things or just let you do it on 1 bit of information in > tapscript. > > > > If I'm understanding you right, then what you're signing is your choice > of sighash flags, rather than anything inherent to the transaction. So I > don't think this works. > > -- > Andrew Poelstra > Director, Blockstream Research > Email: apoelstra at wpsoftware.net > Web: https://www.wpsoftware.net/andrew > > The sun is always shining in space > -Justin Lewis-Webster > > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/9e48edb6-1909-4eee-a0c7-48123f42a198n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 5530 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread

end of thread, other threads:[~2024-05-11 16:27 UTC | newest]Thread overview:18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-04-29 0:30 [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) Ethan Heilman 2024-04-30 12:32 ` Matthew Zipkin 2024-04-30 13:25 ` Ethan Heilman 2024-04-30 14:21 ` Andrew Poelstra 2024-04-30 20:43 ` Ethan Heilman 2024-05-01 3:46 ` Antoine Riard 2024-05-01 20:02 ` Ethan Heilman 2024-05-06 7:39 ` David A. Harding 2024-05-06 16:48 ` Andrew Poelstra 2024-05-06 18:56 ` David A. Harding 2024-05-06 19:06 ` Andrew Poelstra 2024-05-07 0:55 ` Antoine Riard 2024-05-07 16:05 ` Ethan Heilman 2024-05-07 4:11 ` David A. Harding 2024-05-07 14:34 ` Andrew Poelstra 2024-05-09 0:31 ` Ben Carman 2024-05-09 12:46 ` Andrew Poelstra 2024-05-11 2:53 ` Antoine Riard

This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox