From: Jeremy Rubin <jeremy.l.rubin.travel@gmail•com>
To: jl2012@xbt•hk
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability
Date: Thu, 23 Jul 2015 14:05:12 +0800 [thread overview]
Message-ID: <CAJ+8mENg0WshSjuF_vWquScHJ1nqZKOTHyqwMTKiMC1JOEkLFA@mail.gmail.com> (raw)
In-Reply-To: <20150723045546.Horde.KiM4VIQqwnFJ3lwdFrO-2w3@server47.web-hosting.com>
[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]
A standard transaction is 225 bytes, leading to a savings of 8.6%.
However, that is essentially the minimum saving. For other sizes (eg, 10
outputs) which seem to be pretty frequent savings can be greater.
Furthermore, it is important to note that this is a memory saving for the
UTXO pool so the reduction there is more (not super familiar with how the
UTXO pool is stored, but it should be a better savings than 8.6%).
Does anyone have the tools currently to be able to easily run through the
chain and analyze the impact of this change on historical data more
directly?
On Thu, Jul 23, 2015 at 12:55 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Quoting Gavin Andresen via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org>:
>
> On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <
>> bitcoin-dev@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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3228 bytes --]
prev parent reply other threads:[~2015-07-23 6:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 20:15 Jeremy Rubin
2015-07-22 20:34 ` Tier Nolan
2015-07-22 21:06 ` Gavin Andresen
2015-07-23 4:05 ` Jeremy Rubin
2015-07-23 4:55 ` jl2012
2015-07-23 6:05 ` Jeremy Rubin [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=CAJ+8mENg0WshSjuF_vWquScHJ1nqZKOTHyqwMTKiMC1JOEkLFA@mail.gmail.com \
--to=jeremy.l.rubin.travel@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/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