📅 Original date posted:2015-12-29
📝 Original message: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 at lists.sourceforge.net/msg03200.html
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 [ARCHIVE] /
npub14v…jyksm
2023-06-07 17:47:21
in reply to nevent1q…gj3h
Author Public Key
npub14vwgt02663pkxx54kg5t693shaavmvnldhsp49sve7asw7p36lkqljyksmPublished at
2023-06-07 17:47:21Event JSON
{
"id": "af33b86d5a566c2006286c19ddf9f53ce55b59f92de44797c7ade859f18478b0",
"pubkey": "ab1c85bd5ad443631a95b228bd1630bf7acdb27f6de01a960ccfbb077831d7ec",
"created_at": 1686160041,
"kind": 1,
"tags": [
[
"e",
"0600edb122b23d28de1adba7ca47e2347d6be937da11235e57408ba908190104",
"",
"root"
],
[
"e",
"d9fd033b4ec44765f9b73d927aefc187017fd07865ec762176c9c418c2c851e7",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-12-29\n📝 Original message:Do we need to consider that someone may have a timelocked big tx, with \nprivate key lost?\n\nI think we need to tell people not to do this. Related discussion:\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011656.html\n\n\nPeter Todd via bitcoin-dev 於 2015-12-29 00:35 寫到:\n\u003e Occured to me that this hasn't been mentioned before...\n\u003e \n\u003e We can trivially fix the quadratic CHECK(MULTI)SIG execution time issue\n\u003e by soft-forking in a limitation on just SignatureHash() to only return\n\u003e true if the tx size is \u003c100KB. (or whatever limit makes sense)\n\u003e \n\u003e This fix has the advantage over schemes that limit all txs, or try to\n\u003e count sigops, of being trivial to implement, while still allowing for a\n\u003e future CHECKSIG2 soft-fork that properly fixes the quadratic hashing\n\u003e issue; \u003e100KB txs would still be technically allowed, it's just that\n\u003e (for now) there'd be no way for them to spend coins that are\n\u003e cryptographically secured.\n\u003e \n\u003e For example, if we had an issue with a major miner exploiting\n\u003e slow-to-propagate blocks(1) to harm their competitors, this simple fix\n\u003e could be deployed as a soft-fork in a matter of days, stopping the\n\u003e attack quickly.\n\u003e \n\u003e 1) \n\u003e www.mail-archive.com/bitcoin-development at lists.sourceforge.net/msg03200.html\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "cb12e0d6bb473426ac115a4c00480a05c24f0c51440a7e9e1a3e2bc5395c8c304ca1821d3d0f76dd0538458842c000e6c49124c96e07e4c56354d10e25ac0fb0"
}