Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)

[Ethan Heilman]

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/

[Matthew Zipkin]

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.

--
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+...@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.

[Ethan Heilman]

> 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."

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.

[Andrew Poelstra]

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

[Ethan Heilman]

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.

[Antoine Riard]

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

[Ethan Heilman]

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.

> --
> 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+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n%40googlegroups.com.

[David A. Harding]

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

[Andrew Poelstra]

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.

[David A. Harding]

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

[Andrew Poelstra]

You can implement ECDSA. It will just take a *lot* of opcodes.

[Antoine Riard]

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

[David A. Harding]

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

[Andrew Poelstra]

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.

[Ethan Heilman]

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

[Ben Carman]

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

[Andrew Poelstra]

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.

[Antoine Riard]

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