From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 02 May 2024 17:19:51 -0700 Received: from mail-oi1-f184.google.com ([209.85.167.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s2geU-0007B1-M7 for bitcoindev@gnusha.org; Thu, 02 May 2024 17:19:51 -0700 Received: by mail-oi1-f184.google.com with SMTP id 5614622812f47-3c7533a4a7csf2368745b6e.0 for ; Thu, 02 May 2024 17:19:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714695584; cv=pass; d=google.com; s=arc-20160816; b=yY0Cqi9ZhKgX0ryzJf+u38cu26Jg+dlOJpb9mq7TiORogxthFWpsC6vdlqbfGnM1Vm qsNDqAavQt4FxhyWlMwT3DWPvxBdJ9jcHbWhO2EFRbzDkfDZQLVwnr46Sg9hhVOGM4d4 SKECHRXyYyecImapYHU3rHhMTrXDTNqK5q1056KYMkRQpAu4MyOJIFLHX3y6DGh7l3rq M2z6yZIK1kX1vAA5+FIX7biSSKGfiojUqyNoghCw8U83ZfOJj73R/2xqCXequrWxRuBW Y1CTz/5o+yzDB6c9msWxLO7vbCCiBktRbrCv3opX1VHqQdczhT40JkbBGVe/pxjD11rK emXQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding:cc:to :subject:message-id:date:from:in-reply-to:references:mime-version :sender:dkim-signature:dkim-signature; bh=2oaA5iJEssST5ygfAK7geVD0+dhTdEQ9+fxT9vvqlJc=; fh=KM8+yrWG6eExTOpDWBX6adJcNpDVsSSbff4COFlVNO0=; b=BT7Q6ZwegbKLacIIA+8gniBLqK5ltZa2eOtBGLSjQLuqama0u7ZTCaUteQqGYQ8hic 1NflTUIqIirdPk6W+4YFPFAKvkq3n0INozsiLx+YTVCaMDbCM6S7/ogKoMs4rA4mjAh+ FZofFcbe1302HAvlYkMJx3bjWM9t4q8naqT2pC6Lxt1WTxWtFLPNlnYSdysbpVJe8/qQ Sd/NJGaVuBbi6r4L3Gx4ooXAf8ptHa3rCTXA+9h5OrspFA70rQzQ5hDnKfn0/VSy/Cje iklJBX4SZEwiNv39BIpYvE4jHm35M6MiNp5BZCey2r6vmd8hdn2xcDyG+XVVuGShMTCP sdag==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=OVCX6Qcr; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1714695584; x=1715300384; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:sender :from:to:cc:subject:date:message-id:reply-to; bh=2oaA5iJEssST5ygfAK7geVD0+dhTdEQ9+fxT9vvqlJc=; b=JrinQ3WMqvbJSRiBhgDo1M8990GQnG1TwoFqPMHJ8ku9LnZoDb66Faea4Gq5scikhK wlT0i3LF7qh+BnpCrjQhykKsMFG7CZ4YI+tIV3U+pzyCQqInSEkvawof0JntjJAOAHms 6dbrwocnk2DrQnB3XNC8qDowSRG2PfGcoxElIMorg/RW57KIzNGfLi+YpsPWGrAFJ8RN yKUg9j0Xj+xVZ1sCcKNS641g30DIsB/A5C/zlrtCFAGN3eamuq+QoJcy/kh1kctlU2x4 dxgehdbVqXecO+8x62P68LONjBEzTkl1R5hZ5e1iX9pxLqqsVK3cmFHK3U+utxasCTRJ RfBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714695584; x=1715300384; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=2oaA5iJEssST5ygfAK7geVD0+dhTdEQ9+fxT9vvqlJc=; b=QkqjJxeQBYY0Ehg/CRux0OKFxBMM1L4WXM3Fr5L+s4pMXEioR27UhDxKU38Uws98f0 UKPHls6SHLFWr9/s6VE1S5vk7+JCoeO+I/sVSqWtjRLh75oy4h/NWC0+zb2hq7g3+fXf jFQrwfylAzncC14/hDLFGIdDB7XwohLBRPE2iDbQb/xByWJpXieyGf8w2S/CgTC+7M0T ybYRVI9VdWA1140vYh1/AqQugCU/py7k+M7FlTZfiINeBRVKdUS7qN3e01GuWxKCOXz/ JDqz8Pi3txgJsMnfHN6tW/0KmhiiqmUWxWc/2k6V+wRAKI2qzpAIpig4YyiEB+bKIRzD iLCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714695584; x=1715300384; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=2oaA5iJEssST5ygfAK7geVD0+dhTdEQ9+fxT9vvqlJc=; b=w0nlqwfiSQqK0HX/DuQY8dcZQ4tfG60VB7KnqeCBULrIp48RLMlORT7s1H3W3WCd3Z f9zu7D6wvwsETJ0zgMKlExcLECq+eeEQObH6UyqU8KNIHAHlPl1yZQbuxOCpR6bmlBK8 YOGsF7UtzYisE4f2R8Fj81mSYmcHZpkNdDs8XsLzZgBg9faRNZnu2K/fhxhGN7089QFF hcyyI+jB7p+uIAFmw+ijy+ps+91tIe2yKvcIzR+Shs3tjn4UhyoxgkFFeDjDanAJuFJf J3txexwy83h5LJvWVlkzL7dGFzraIokNtJAL+xQER99ak6LTk3SgeNc7PIDzVhj+7WeM 6lQA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUqXEx1XokXAbl6ntgm7pVprpGBDF7n02CuX24Ol35T3sBAhfwt4Fd1As+wJWGEGtlpManaHf5tI464abKMKp7RS1kX4zk= X-Gm-Message-State: AOJu0YxfbCLxzuURoikQ5EOHeJ+0HkC0+1a2+inMdEYJIeOmiuvQiHW8 U2HGf1ROLKHck0n1dMb1ZACShqerIlPwFmMZOaBZMgEbUDHC9Xxs X-Google-Smtp-Source: AGHT+IFoA6hkrko4PrcfNFTTgwOWKzec8QCQcGWQusWeiS469Z1emero7J1cp/ygEd1ggVAXrSj7og== X-Received: by 2002:a05:6808:30a2:b0:3c8:64c2:73fa with SMTP id bl34-20020a05680830a200b003c864c273famr1840895oib.0.1714695584537; Thu, 02 May 2024 17:19:44 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:414:b0:6a0:c024:81e with SMTP id 6a1803df08f44-6a0fefd6d35ls19660846d6.2.-pod-prod-07-us; Thu, 02 May 2024 17:19:43 -0700 (PDT) X-Received: by 2002:a05:6214:21a2:b0:6a0:3f4f:1762 with SMTP id t2-20020a05621421a200b006a03f4f1762mr56324qvc.0.1714695582997; Thu, 02 May 2024 17:19:42 -0700 (PDT) Received: by 2002:a05:620a:470e:b0:790:f573:2ec2 with SMTP id af79cd13be357-79271263869ms85a; Wed, 1 May 2024 13:03:10 -0700 (PDT) X-Received: by 2002:a05:600c:444a:b0:41b:fd63:1981 with SMTP id v10-20020a05600c444a00b0041bfd631981mr71534wmn.41.1714593788606; Wed, 01 May 2024 13:03:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1714593788; cv=none; d=google.com; s=arc-20160816; b=FOuw7QYno3tg/ezb37qKzGDT838ih2Gp6qsL1SHTii+Ua94BH84sEmvSo6kIZ7Rf+1 iakGlsBSLWsVPj9Q15NphkRvNAoYuJVaVzJ0TOpfsF6dbzzNjABjUN2s2W6jXRFj3ZTN hTRXYYgf1aBveZexwZ9FXTe7iADvYlLe1st2C9eehV2Zh6tyzZz9RCp6fDXArCixwjfY Fml1zRAQML6KU92ZLLj3N4mnAyaEkxC0L/295nLnzlUKn+EtPFxoBuICWMhzudGDn6kh hipqFvT82bLzaThMEJo5+KkNDIcnUQKM+67Y4Rz4+5m8AH2lXlexjYCA4DAZabo/pMAq 1cvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=//8TNM9ybUsTWGRmrd9HyEe1QGXH/8BikrYnsZngwtE=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=k/dqXy8Az+DNoMKDo6QB6ewLhfjiHMhGf/GAPSxSfJbTAkwJ4dYh7jh96uGGmx+r9f 0U+ALue+Y9xVJ45kEUM/qP7Hhi20GT1AWLAYtJTMD1bpR1Bnzt75GDSLGWzVs3JjCt/I o5Uh6Az15kI3K7DbSxMn1UHRgi53hs7dgEoTEBds3rQ9wMqUpzk3NNWn8O2h5ygbux2R LoxK3bS+GZQICr9yEsVgwFulWWB+2NUCfqM0cZ8NjcdVW4gUp3Phr+J8ZHtT8qgfXYRI lMoYH5hFDNfXW6jeZIDMYxJuQuwz7KSRZOOJFuSAGZz2qWTYpJMYKf5xxlZIse3yGRkF Ya5Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=OVCX6Qcr; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com. [2a00:1450:4864:20::636]) by gmr-mx.google.com with ESMTPS id ka18-20020a05600c585200b0041ab32f333bsi1359837wmb.1.2024.05.01.13.03.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 May 2024 13:03:08 -0700 (PDT) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::636 as permitted sender) client-ip=2a00:1450:4864:20::636; Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a559b919303so913521666b.1 for ; Wed, 01 May 2024 13:03:08 -0700 (PDT) X-Received: by 2002:a17:906:f28c:b0:a51:e05f:2455 with SMTP id gu12-20020a170906f28c00b00a51e05f2455mr13280ejb.48.1714593787800; Wed, 01 May 2024 13:03:07 -0700 (PDT) MIME-Version: 1.0 References: <2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n@googlegroups.com> In-Reply-To: <2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n@googlegroups.com> From: Ethan Heilman Date: Wed, 1 May 2024 16:02:30 -0400 Message-ID: Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) To: Antoine Riard Cc: Bitcoin Development Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=OVCX6Qcr; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) Hi Antoine, > On the usage of such emulated Lamport signature scheme in a public transa= ction-relay network, there is one fundamental security property of Lamport = signature to be aware off, mainly the one-time usage. So this is very uncle= ar if as soon you're broadcasting the transaction, miners coalition could w= ithhold the transaction inclusion to trigger the initial signer to reveal m= ore 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 p= lay tricks with coordinates. What do you mean by this? k=3D0? 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 stat= e-of-the-art collision attacks on hash functions from recent academic liter= ature. 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=E2=80=AFAM Antoine Riard wrote: > > Hi Ethan, > > From my understanding, you're proposing to emulate Lamport signature veri= fication / generation > scheme by leveraging the implicit signature digest of the OP_CHECKSIG ope= ration, 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 ECDS= A and Schnorr schemes. > > Here you're proposing to use the ECDSA's `k` nonce as a fixed public valu= e 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) =3D y for L= amport 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 at= tacks or invalid curve > domain parameters, e.g using the point at infinity as your point R, and i= f from them you could play > tricks with coordinates. > > On the usage of such emulated Lamport signature scheme in a public transa= ction-relay network, > there is one fundamental security property of Lamport signature to be awa= re off, mainly the one-time > usage. So this is very unclear if as soon you're broadcasting the transac= tion, miners coalition could > withhold the transaction inclusion to trigger the initial signer to revea= l more a lot of pre-committed > fixed-nonce ECDSA signatures. > > Apart of concerns of this scheme in a blockchain and assuming it's not ut= terly 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 fi= xed-nonce signatures we're making > it harder to break, even for observers with significant computational res= sources. > > Beyond, 2^64 bit of security doesn't seem a lot in considerations of stat= e-of-the-art collision attacks > on hash functions from recent academic literature. And one have to consid= er how you can take the > short-cut by pre-computing rainbow tables for ECDSA r-value of a given si= gnature size. > > I think a more interesting open question of this post is if we have alrea= dy 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 scri= ptSig / witness under current block > size limit of 4MWU. > > Best, > Antoine > Le mardi 30 avril 2024 =C3=A0 22:18:36 UTC+1, Ethan Heilman a =C3=A9crit = : >> >> 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, i= nstead Lamport (or WOTS) signs a vector of the positions of the low-length = ECDSA signatures (low length here means length=3D58 rather than length=3D59= ). Then the redeem script would only check the length of those particular s= ignatures and could drop the other other public keys. This saves significan= tly on the number of opcodes because we only need to check the Lamport sign= ature on the vector, no one each signature length and we can drop unused ch= ecked signatures without evaluating them. >> >> Alice's advantage over the attacker is that she gets to fix the position= s of the low length ECDSA signatures after she generates them. This means i= f the total number of signatures is N and the number of low length signatur= es is M, her advantage over the attacker is (N choose M). For instance if N= =3DM=3D10, 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-byt= e ECDSA signature is 1/256 (1/2^8). However if N=3D40, M=3D10 she only need= s to perform 2^(8*10)/(40 choose 10) work. >> >> If we assume that we want 80 bits of security, this means we need M=3D10= low length ECDCSA signatures (2^(8*10)). The next parameter is how cheap w= e want this to be for Alice to compute, we can boost Alice's signing time b= y increasing N and remove log2(N choose 10) from the work she needs to comp= ute the signature. If we want to ensure Alice has to do no more than 2^32 w= ork to sign, then we need N=3D46 or 46 ecdsa signatures. >> >> On Tue, Apr 30, 2024 at 10:21=E2=80=AFAM 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=3D1 point and for them to publish this). >>> >>> Another reason this is useful is that if you have a Lamport signature o= n >>> 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 ca= n >>> 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/msgi= d/bitcoindev/2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n%40googlegroups.com. --=20 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 e= mail 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.