From: Jordan Mack <jordanmack@parhelic•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Pubkey addresses
Date: Sat, 17 Dec 2011 10:20:15 -0800 [thread overview]
Message-ID: <4EECDD5F.8030402@parhelic.com> (raw)
In-Reply-To: <1324138546.29801.3.camel@BMThinkPad.lan.bluematt.me>
While I think firstbits is an interesting idea, I agree with Matt on
this one. Firstbits, while being a clever idea, produces a less
desirable solution in comparison to the current alias proposals.
In addition to Matt's reasons, I would like to add that it is still a
block of random characters, just shorter. It creates the undesirable
effect of having addresses short enough that people may try to type it
in rather than pasting or scanning, which is more error prone.
One obvious scenario for potential exploitation would be if a large
organization adopted a firstbits address for donations. Others could
immediately try to collect similar addresses in hopes of a typo. A
second would be if the organization published the firstbits address on a
poster in a public location. Someone could easily secure a firstbits
address which was one character longer, then stencil that extra
character on to the poster.
On 12/17/2011 8:15 AM, Matt Corallo wrote:
> On Sat, 2011-12-17 at 12:14 +0100, Jorge Timón wrote:
>> Don't know much about QR codes, but I thought they have a length limitation.
>> Why jav wants to use not just addresses but firstbits then?
> Under no circumstances should the use of firstbits ever be supported.
> It doesn't scale, not even close, especially as we (hopefully) move
> towards SPV clients. Also, it provides incentives for people to spam
> the chain to get a firstbits address. Never should that be supported.
>
> Matt
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
next prev parent reply other threads:[~2011-12-17 18:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-17 6:32 Luke-Jr
2011-12-17 11:14 ` Jorge Timón
2011-12-17 16:15 ` Matt Corallo
2011-12-17 18:20 ` Jordan Mack [this message]
2011-12-18 12:15 ` Jorge Timón
2011-12-18 14:03 ` Luke-Jr
2011-12-18 14:28 ` Jorge Timón
2011-12-18 14:34 ` Luke-Jr
2011-12-18 15:42 ` Pieter Wuille
2011-12-18 19:50 ` Jorge Timón
2011-12-17 13:54 ` Wladimir
2011-12-17 21:52 ` Luke-Jr
2011-12-17 23:46 ` Gregory Maxwell
2011-12-18 0:28 ` Luke-Jr
2011-12-18 0:39 ` Luke-Jr
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=4EECDD5F.8030402@parhelic.com \
--to=jordanmack@parhelic$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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