📅 Original date posted:2015-07-23 📝 Original message:Quoting Gavin Andresen via ...

jl2012 at xbt.hk [ARCHIVE] /

npub1kc0…jfw4

2023-06-07 15:43:15

in reply to nevent1q…kymr

📅 Original date posted:2015-07-23
📝 Original message:Quoting Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org>:

> On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> It also requires most clients to be updated to support the new address
>> system.
>
>
> That's the killer: introducing Yet Another Type of Bitcoin Address takes a
> very long time and requires a lot of people to change their code. At least,
> that was the lesson learned when we introduced P2SH addresses.
>
> I think it's just not worth it for a very modest space savings (10 bytes,
> when scriptSig+scriptPubKey is about 120 bytes), especially with the
> extreme decrease in security (going from 2^160 to 2^80 to brute-force).
>
> --
> --
> Gavin Andresen

I think it would only save ~5% with all overhead (value, sequence,
locktime, version, etc.) counted

A better way is to introduce shorter ECDSA keys, which will save a lot
of space for public key and signature. It is safe as long as the
output value is much lower than the cost of attack.

If this happens, I think it will be part of the OP_MAST which will
require a new address type anyway.

Author Public Key

npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4

Show more details

Published at

2023-06-07 15:43:15

Kind type

1 Short Text Note

Event JSON

{ "id": "7bcbdeacbd0bc9d6364cb8ab62a58f4d157bbb73c48862d996d6d40abcf0ebb1", "pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa", "created_at": 1686152595, "kind": 1, "tags": [ [ "e", "c930b66ac9bba5c339fe9fa3b5470a0d2792ed6e412775967d6cc963ca45f737", "", "root" ], [ "e", "1b85da4fc9db1c1c54bf29b72d82ffb62b1c420b9bcb10058978912400c68935", "", "reply" ], [ "p", "372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a" ] ], "content": "📅 Original date posted:2015-07-23\n📝 Original message:Quoting Gavin Andresen via bitcoin-dev \n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e It also requires most clients to be updated to support the new address\n\u003e\u003e system.\n\u003e\n\u003e\n\u003e That's the killer: introducing Yet Another Type of Bitcoin Address takes a\n\u003e very long time and requires a lot of people to change their code. At least,\n\u003e that was the lesson learned when we introduced P2SH addresses.\n\u003e\n\u003e I think it's just not worth it for a very modest space savings (10 bytes,\n\u003e when scriptSig+scriptPubKey is about 120 bytes), especially with the\n\u003e extreme decrease in security (going from 2^160 to 2^80 to brute-force).\n\u003e\n\u003e --\n\u003e --\n\u003e Gavin Andresen\n\nI think it would only save ~5% with all overhead (value, sequence, \nlocktime, version, etc.) counted\n\nA better way is to introduce shorter ECDSA keys, which will save a lot \nof space for public key and signature. It is safe as long as the \noutput value is much lower than the cost of attack.\n\nIf this happens, I think it will be part of the OP_MAST which will \nrequire a new address type anyway.", "sig": "fdaa367ddfcc65707ca7471bc2649cd2e492046529b9c2f5c8f721294950c66b56f70400d24bcce26a41186d052af9442024962186ce43e0c4bef11c21bb0055" }