From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)
Date: Fri, 10 May 2024 19:53:53 -0700 (PDT) [thread overview]
Message-ID: <9e48edb6-1909-4eee-a0c7-48123f42a198n@googlegroups.com> (raw)
In-Reply-To: <ZjzFtus_aBchwKz2@camus>
[-- 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 --]
prev parent reply other threads:[~2024-05-11 16:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 0:30 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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e48edb6-1909-4eee-a0c7-48123f42a198n@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox