MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 29 Dec 2015 02:47:22 -0500
From: jl2012 <jl2012@xbt.hk>
To: Peter Todd <pete@petertodd.org>
In-Reply-To: <20151229053559.GA8657@muck>
References: <20151229053559.GA8657@muck>
Message-ID: <26ec8367f2a1cda066b19e0bff498711@xbt.hk>
User-Agent: Roundcube Webmail/1.0.6
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] We can trivially fix quadratic CHECKSIG with a
 simple soft-fork modifying just SignatureHash()
Precedence: list

Do we need to consider that someone may have a timelocked big tx, with 
private key lost?

I think we need to tell people not to do this. Related discussion:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011656.html


Peter Todd via bitcoin-dev 於 2015-12-29 00:35 寫到:
> Occured to me that this hasn't been mentioned before...
> 
> We can trivially fix the quadratic CHECK(MULTI)SIG execution time issue
> by soft-forking in a limitation on just SignatureHash() to only return
> true if the tx size is <100KB. (or whatever limit makes sense)
> 
> This fix has the advantage over schemes that limit all txs, or try to
> count sigops, of being trivial to implement, while still allowing for a
> future CHECKSIG2 soft-fork that properly fixes the quadratic hashing
> issue; >100KB txs would still be technically allowed, it's just that
> (for now) there'd be no way for them to spend coins that are
> cryptographically secured.
> 
> For example, if we had an issue with a major miner exploiting
> slow-to-propagate blocks(1) to harm their competitors, this simple fix
> could be deployed as a soft-fork in a matter of days, stopping the
> attack quickly.
> 
> 1) 
> www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev