public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeremy Rubin <jeremy.l.rubin.travel@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability
Date: Thu, 23 Jul 2015 12:05:22 +0800	[thread overview]
Message-ID: <CAJ+8mEP5dCmRbm7-FY5v+mO+jwB-=LnTVDo=5+AML4oAUgTwuw@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T21i_onZcj=zcY=rvbxQtVUh=cW-TYxYNqwxcFxA5hKvQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]

I think the catch here is that under STUA (short term use address) there is
a strict incentive, you can reduce the transaction fee for these txns. This
also fits with the general model that you pay the miners for security. My
belief is that when there is a savings benefit to be had large players will
prefer it at a minimum, and users will desire it.


Your analysis of saving is inaccurate, it comes to be at or greater than 20
bytes because there is typically 2 UTXOs or more. I get that this is still
marginal, but when the margins are tight this is a pretty decent gain.


The security decrease is actually less extreme than it seems. This is for
multiple reasons:
1) you can select LEN_PARAM when you make the tx to be secure at that time
Adding a byte or two gets much more security while still keeping it lean.
2) For a small transaction, the hash power is less rewarding than just
working on the blockchain or doing something else
3) These addresses are only for use for short term, not perm storage. As
such, if you model the threat it isn't great (I'm using this address for
one day, someone grinds it in that time).
4) Because it is a UTXO saving, it reduces memory bloat.t

It would be interesting to get a more exact analysis on the time needed to
run a brute force as it involves computing a valid keypair and hashing for
each attempt.



On Thu, Jul 23, 2015 at 5:06 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3491 bytes --]

  reply	other threads:[~2015-07-23  4:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 20:15 [bitcoin-dev] BIP: Short Term Use Addresses for Scalability Jeremy Rubin
2015-07-22 20:34 ` Tier Nolan
2015-07-22 21:06   ` Gavin Andresen
2015-07-23  4:05     ` Jeremy Rubin [this message]
2015-07-23  4:55     ` jl2012
2015-07-23  6:05       ` Jeremy Rubin

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+8mEP5dCmRbm7-FY5v+mO+jwB-=LnTVDo=5+AML4oAUgTwuw@mail.gmail.com' \
    --to=jeremy.l.rubin.travel@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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