Re: [Bitcoin-development] Stealth Addresses

[Gregory Maxwell]

On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner  wrote:
> Isn't there a much faster asymmetric scheme that we can use?  I've heard 
> people talk about ed25519, though I'm not sure it can be used for encryption.

Doing ECDH with our curve is within a factor of ~2 of the fastest
encryption available at this security level, AFAIK.  And separate
encryption would ~double the amount of data vs using the ephemeral key
for derivation.

Using another cryptosystem would mandate carry around additional code
for a fast implementation of that cryptosystem, which wouldn't be
fantastic.

So I'm not sure much can be improved there.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

*Avoiding ECDH calcs on every blockchain transaction (and avoiding the
prefix thing):*

Can we skip the whole ECDSA/ECDH thing, and use the second key pair for
encryption instead?  Then we don't need any ephemeral keys.  We use the
much simpler scheme like I mentioned before (just root keys and
multpliers), but instead of requesting a multiplier from the person
receiving the money, the payer can create their own multiplier and
encrypt it into an OP_RETURN msg (using the secondary public key of the
receiver).  When they do this, they append a deterministic identifier to
it, so that the receiver can immediately identify it upon decryption.

Basically, the receiver simply attempts decryption of every OP_RETURN
message, and if the identifier is there, they immediately know that the
tx is theirs, and that the other bytes of the decrypted message is the
multiplier used.

Of course, using something like ECIES and forcing the receiver to
attempt decryption of every OP_RETURN tx may not be any faster than the
ECDH we've already talked about here.  But with this, we are not tied to
any particular crypto.  Isn't there a much faster asymmetric scheme that
we can use?  I've heard people talk about ed25519, though I'm not sure
it can be used for encryption.  I'd bet money there is an asymmetric
_/encryption/_//algorithm that would be fast enough to not burden the
receiver.

Here's how I envision it:

--Alice gives out her business card that has public key X (BIP32 root),
and public key Y (fastCrypto)
--Bob generates a random 32-byte nonce, and EC-multiplies Alice's public
key by it.   He prepares a transaction sending coins to that address (Z)
--Bob also computes a deterministic identifier, perhaps hash(pubKeyX ||
addrZ)[8:].  Bob appends the those 8 bytes to the multiplier, and
encrypts all of it with Alice's fastCrypto key, Y.   He puts that
message in the OP_RETURN output.
--Alice's wallet will attempt decryption of every OP_RETURN message. 
First she computes hash(pubKeyX, addrZ)[8:], and then decrypts the
message with the fastCrypto private key.  If the tx is actually hers,
the last 8 bytes will match the identifier, and she knows to use the
other 32 bytes as a multiplier.  If it doesn't, it's irrelevant to her
and she moves on.

[**Should probably use 24-byte values for the multipliers (or hashes of
24-byte values), so that adding 8 bytes makes the whole message an even
32 bytes which is better for encryption]

Doesn't this have the exact same properties as the original proposal
(including compatibility with CoinJoin)?  But it all depends on having
fast asymmetric encryption.

-Alan



--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

[Luke-Jr]

On Friday, January 17, 2014 8:53:47 PM Jeff Garzik wrote:
>   BitPay sure would like to see CPFP in upstream.
> 
> I think the main hurdle to merging was that various people disagreed
> on various edge case handling and implementation details, but no
> fundamental objections.

Heck, even I disagree with implementation details, but it's still better than 
nothing. We can always merge major reorganisations/reimplementations later 
when they're written: merging this one doesn't mean we're stuck with it 
forever...

Luke

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CPFP is *extremely* important. People have lost money because this
feature is missing. I think it's critical that it makes it into 0.9

If I get a low-priority donation from a blockchain.info wallet, that
money can disappear if it doesn't make it into a block in 24 hours -
bc.i will forget the transaction and happily respend its inputs on the
next transaction that user makes.

I wouldn't mind paying $1 in fees to receive a $50 donation. But
without CPFP there's no way to do that.


On 01/17/2014 12:53 PM, Jeff Garzik wrote:
>   BitPay sure would like to see CPFP in upstream.
> 
> I think the main hurdle to merging was that various people
> disagreed on various edge case handling and implementation details,
> but no fundamental objections.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS2ZrQAAoJEAdzVfsmodw4CrwP+gM2iXLcvQK2VlhoN7kRCnvH
+YJ87fXlMl0IcRqVDyaCF6w3+U/9VG+p+/eFvBNzxMMTbylWbsSXF6GxavwPhVt4
zw//VNLIfOu+88HsUofamvZJGHQOArwzlOYRgX1Lr9ms3KSQ2QWkW+Z6QD7qmkO2
bJNzxJ+vffmz24mQ6hg7a33YW+403TbeqxcPewbjNr76hvPEjzlTPhpVo4A/gqSu
6rcJPQIkFdTZX/xy5hyZsQzswNv/bYyrE9XhEIimsqt96sjTDrB4EZKzfkQ/jLeP
fudEcGEvRzJL9BSsa6mfUBzct2ilpii33q1vIIVYfIQIJmYl7U6YubloT235l2C7
0v0RWn5Kux2R9B4YFKjR09Jc2273mrnGuUj7hKD0LPHfn/Jzxy1Ce4AIcaodlgwP
u7vpvWiVEUcJkl3rn3enAyKCtD7zqe4k73ALq4yWjnDZRFEQ9DJEdEPEy+H8HlXY
RFOtFxAr/Vdyp9STAgjve46M4g/Qc5C10qIueTyJO1h8XDPfV8HnZJNVJP3wtj0K
pC5vq7ADxkQ60F9w+vNEdo85AVWhITQ/Kq7dbSq5J1LxddivzRurnp2uX+U2LEkV
9Hd2HuIM7E4uR0JZKRqPsFCJrpBuI4YPGHQB5pbq9eYAG4BdmTwTXUvd2FacI3mL
beN/c4m26MKQJTiMQyTl
=u7Qb
-END PGP SIGNATURE-

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

[Jeff Garzik]

  BitPay sure would like to see CPFP in upstream.

I think the main hurdle to merging was that various people disagreed
on various edge case handling and implementation details, but no
fundamental objections.


On Fri, Jan 17, 2014 at 1:41 PM, Luke-Jr  wrote:
> On Friday, January 17, 2014 11:44:09 AM Wladimir wrote:
>> On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr  wrote:
>> > https://github.com/bitcoin/bitcoin/pulls/luke-jr
>> >
>> > These are pretty much all well-tested and stable for months now.
>>
>> #3242: Autoconf improvements needs rebase, and comment from jgarzik and me
>> taken into account (about -enable-frontends=).
>
> I'll try to get this done over the weekend.
>
>> The others appear to be more controversial as they affect mining/consensus.
>> I'd really like to see ACKs from more reviewers and testers there before
>> merging.
>
> Can you elaborate on this? I can see how Proposals might, if buggy, affect
> consensus, but the rest shouldn't. I don't think there's anything
> controversial in any of these (does someone disagree with CPFP?).
>
> Luke
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[Cameron Garnham]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

One of the possible words that haven't been proposed is 'personal' where
bitcoin addressed are commonly incorrectly called public address.

Maybe 'personal account' or even 'personal address' would imply that the
balance on such an account shouldn't be assumed to be public knowledge.

Cam.


On 17/01/2014 5:59 pm, Drak wrote:
> That could also work. Still, didn't we want to ditch the word address?
> Could be a privacy key...
> 
> On 17 Jan 2014 09:15, "Mike Hearn"  > wrote:
> 
> I must say, this shed is mighty fine looking. It'd be a great place
> to store our bikes. But, what colour should we paint it?
> 
> How about we split the difference and go with "privacy address"? As
> Peter notes, that's what people actually like and want. The problem
> with stealth is it's got strong connotations with American military
> hardware and perhaps thieves sneaking around in the night:
> 
>https://www.google.com/search?tbm=isch&q=stealth
> 
> But everyone loves privacy.
> 
> 
> On Fri, Jan 17, 2014 at 8:49 AM, Drak  > wrote:
> 
> Peter I agree with you about  "reusable addresses", but aren't
> we also trying to get away from the word "address" entirely?
>  How about calling it a "payment key" or "reusable payment key"
> instead? using "stealth" is just asking for bad press imo.
> 
> 
> On 16 January 2014 21:28, Peter Todd  > wrote:
> 
> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
> > Might I propose "reusable address".
> >
> > I think that describes it best to any non-programmer, and
> even more
> > so encourages wallets to present options as 'one time use' vs
> > 'reusable'.
> >
> > It definitely packs a marketing punch which could help drive
> > adoption. The feature is only useful if/when broadly adopted.
> 
> I'm very against the name "reusable addresses" and strongly
> belive we
> should stick with the name stealth addresses.
> 
> You gotta look at it from the perspective of a user; lets
> take standard
> pay-to-pubkey-hash addresses: I can tell my wallet to pay
> one as many
> times as I want and everything works just great. I also can
> enter the
> address on blockchain.info 's search
> box, and every transaction related
> to the address, and the balance of it, pops up immediately.
> 
> What is that telling me? A: Addresses starting with "1" are
> reusable. B:
> Transactions associated with them appear to be public knowledge.
> 
> Now I upgrade my wallet software and it says I now have a
> "reusable"
> address. My reaction is "Huh? Normal addresses are reusable,
> what's
> special about this weird reusable address thing that my
> buddy Bob's
> wallet software couldn't pay." I might even try to enter in
> a "reusable"
> address in blockchain.info , which
> won't work, and I'll just figure
> "must be some new unsupported thing" and move on with my life.
> 
> On the other hand, suppose my wallet says I now have
> "stealth address"
> support. I'm going to think "Huh, stealth? I guess that
> means privacy
> right? I like privacy." If I try searching for a stealth
> address on
> blockchain.info , when it doesn't
> work I might think twig on "Oh right!
> It said stealth addresses are private, so maybe the
> transactions are
> hidden?" I might also think "Maybe this is like
> stealth/incognito mode
> in my browser? So like, there's no history being kept for
> others to
> see?" Regardless, I'm going to be thinking "well I hear
> scary stuff
> about Bitcoin privacy, and this stealth thing sounds like
> it's gonna
> help, so I should learn more about that"
> 
> Finally keep in mind that stealth addresses have had a tonne
> of very
> fast, and very wide reaching PR. The name is in the public
> conciousness
> already, and trying to change it now just because of vague bad
> associations is going to throw away the momentum of that
> good PR and
> slow down adoption. Last night I was at the Toronto Bitcoin
> Meetup and I
> based on conversations there with peopl

Re: [Bitcoin-development] Stealth Addresses

[Ben Davenport]

Well, at least we don't have to worry about cache invalidation.

Ben


On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd  wrote:

> On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> > I must say, this shed is mighty fine looking. It'd be a great place to
> > store our bikes. But, what colour should we paint it?
>
> I think we should paint it this colour:
>
> They had uncovered what seemed to be the side of a large coloured
> globule embedded in the substance. The colour, which resembled some
> of the bands in the meteor's strange spectrum, was almost impossible
> to describe; and it was only by analogy that they called it colour
> at all.  Its texture was glossy, and upon tapping it appeared to
> promise both brittle ness and hollowness. One of the professors gave
> it a smart blow with a hammer, and it burst with a nervous little
> pop. Nothing was emitted, and all trace of the thing vanished with
> the puncturing. It left behind a hollow spherical space about three
> inches across, and all thought it probable that others would be
> discovered as the enclosing substance wasted away.
>
> I think it really gets to the core of my feelings about this naming
> discussion.
>
> > How about we split the difference and go with "privacy address"? As Peter
> > notes, that's what people actually like and want. The problem with
> stealth
> > is it's got strong connotations with American military hardware and
> perhaps
> > thieves sneaking around in the night:
> >
> >https://www.google.com/search?tbm=isch&q=stealth
>
> WOW! AWESOME KICK-ASS PICS!
>
> Come to think of it, I could have called it "incognito addresses" - a
> term nice enough that Google and Firefox use it in their browsers - but
> what's done is done and any further discussion about this is just going
> to confuse the public. Remember that in the long run all this stuff will
> be hidden behind payment protocols anyway, and users *won't even know*
> that under the hood a stealth address is being used, making the name
> just a technical detail. For now though, lets use the good PR and get
> some early adopters on board.
>
> However, the term 'incognito' probably would be a good one to use within
> wallet software itself to describe what it's doing when the user clicks
> the "I want my transactions to be private" setting - there are after all
> fundemental bandwidth-privacy trade-offs in the threat model supposed by
> both prefix and bloom filters. In this instance the term isn't going to
> go away.
>
>
> Anyway, back to work: For the actual address format I strongly think we
> need to ensure that it can be upgrading in a backwards compatible way.
> This means we have to be able to add new fields - for instance if
> Gregory's ideas for different ways of doing the SPV-bait came to
> fruition. Given that "addresses" aren't something that should stay
> user-visible forever, thoughts on just making the actual data a protocol
> buffers object?
>
> Second question: Any performance figures yet on how efficient scanning
> the blockchain for matching transactions actually is? I'd like to get an
> idea soon for both desktop and smartphone wallets so we can figure out
> what kind of trade-offs users might be forced into in terms of prefix
> length.
>
> --
> 'peter'[:-1]@petertodd.org
> 0001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b
>
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

[Luke-Jr]

On Friday, January 17, 2014 11:44:09 AM Wladimir wrote:
> On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr  wrote:
> > https://github.com/bitcoin/bitcoin/pulls/luke-jr
> > 
> > These are pretty much all well-tested and stable for months now.
> 
> #3242: Autoconf improvements needs rebase, and comment from jgarzik and me
> taken into account (about -enable-frontends=).

I'll try to get this done over the weekend.

> The others appear to be more controversial as they affect mining/consensus.
> I'd really like to see ACKs from more reviewers and testers there before
> merging.

Can you elaborate on this? I can see how Proposals might, if buggy, affect 
consensus, but the rest shouldn't. I don't think there's anything 
controversial in any of these (does someone disagree with CPFP?).

Luke

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Reality Keys trusted oracle service

[Peter Todd]

Finally seeing a more complex script-use-case being implemented:

http://www.coindesk.com/reality-keys-bitcoins-third-party-guarantor-contracts/

Enter Reality Keys, a new service by Tokyo-based startup Social
Minds due for public launch on 20th January. Reality Keys provides
real-world data in a form that can be used to complete or disregard
bitcoin transactions, based on quantifiable facts.

[...]

Users then specify a date at which they would like to confirm the
status or outcome of a particular event, and two cryptographic
public keys are provided: one for if the event happens and another
for if it doesn’t.

[...]

It is all, of course, anonymous. Reality Keys provides only the
keys, and has no interest in or knowledge of the nature of the
contract or the amounts of bitcoin at stake.

-- 
'peter'[:-1]@petertodd.org
d34d6e0e8d8290c7248f32bb3c39400892a34a3e761f6e78


signature.asc
Description: Digital signature
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[Peter Todd]

On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?

I think we should paint it this colour:

They had uncovered what seemed to be the side of a large coloured
globule embedded in the substance. The colour, which resembled some
of the bands in the meteor's strange spectrum, was almost impossible
to describe; and it was only by analogy that they called it colour
at all.  Its texture was glossy, and upon tapping it appeared to
promise both brittle ness and hollowness. One of the professors gave
it a smart blow with a hammer, and it burst with a nervous little
pop. Nothing was emitted, and all trace of the thing vanished with
the puncturing. It left behind a hollow spherical space about three
inches across, and all thought it probable that others would be
discovered as the enclosing substance wasted away.

I think it really gets to the core of my feelings about this naming
discussion.

> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
> 
>https://www.google.com/search?tbm=isch&q=stealth

WOW! AWESOME KICK-ASS PICS!

Come to think of it, I could have called it "incognito addresses" - a
term nice enough that Google and Firefox use it in their browsers - but
what's done is done and any further discussion about this is just going
to confuse the public. Remember that in the long run all this stuff will
be hidden behind payment protocols anyway, and users *won't even know*
that under the hood a stealth address is being used, making the name
just a technical detail. For now though, lets use the good PR and get
some early adopters on board.

However, the term 'incognito' probably would be a good one to use within
wallet software itself to describe what it's doing when the user clicks
the "I want my transactions to be private" setting - there are after all
fundemental bandwidth-privacy trade-offs in the threat model supposed by
both prefix and bloom filters. In this instance the term isn't going to
go away.


Anyway, back to work: For the actual address format I strongly think we
need to ensure that it can be upgrading in a backwards compatible way.
This means we have to be able to add new fields - for instance if
Gregory's ideas for different ways of doing the SPV-bait came to
fruition. Given that "addresses" aren't something that should stay
user-visible forever, thoughts on just making the actual data a protocol
buffers object?

Second question: Any performance figures yet on how efficient scanning
the blockchain for matching transactions actually is? I'd like to get an
idea soon for both desktop and smartphone wallets so we can figure out
what kind of trade-offs users might be forced into in terms of prefix
length.

-- 
'peter'[:-1]@petertodd.org
0001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b


signature.asc
Description: Digital signature
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[joseph]

On naming, please allow consideration of "Confidential address".
Less conflation with "private key", connotes confidence, and as the address is 
known to the transacting parties, it is a precisely accurate name.
 
One of the use cases for these will be in multinational corporate internal 
international settlement.  For a company to use bitcoin for its internal 
settlement and maintain confidence that competitors will not be able to suss 
out its transactions, these confidential addresses will be of great use.
 
 
Stealth connotes stealing, theft, hiding, fear, sneakiness, stealth bombers.  
Maybe it is a good name, but not the best name.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

[Wladimir]

On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr  wrote:

>
> https://github.com/bitcoin/bitcoin/pulls/luke-jr
>
> These are pretty much all well-tested and stable for months now.
>

#3242: Autoconf improvements needs rebase, and comment from jgarzik and me
taken into account (about -enable-frontends=).

The others appear to be more controversial as they affect mining/consensus.
I'd really like to see ACKs from more reviewers and testers there before
merging.

Wladimir
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[Drak]

That could also work. Still, didn't we want to ditch the word address?
Could be a privacy key...
On 17 Jan 2014 09:15, "Mike Hearn"  wrote:

> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
>
>https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak  wrote:
>
>> Peter I agree with you about  "reusable addresses", but aren't we also
>> trying to get away from the word "address" entirely?  How about calling it
>> a "payment key" or "reusable payment key" instead? using "stealth" is just
>> asking for bad press imo.
>>
>>
>> On 16 January 2014 21:28, Peter Todd  wrote:
>>
>>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>>> > Might I propose "reusable address".
>>> >
>>> > I think that describes it best to any non-programmer, and even more
>>> > so encourages wallets to present options as 'one time use' vs
>>> > 'reusable'.
>>> >
>>> > It definitely packs a marketing punch which could help drive
>>> > adoption. The feature is only useful if/when broadly adopted.
>>>
>>> I'm very against the name "reusable addresses" and strongly belive we
>>> should stick with the name stealth addresses.
>>>
>>> You gotta look at it from the perspective of a user; lets take standard
>>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>>> times as I want and everything works just great. I also can enter the
>>> address on blockchain.info's search box, and every transaction related
>>> to the address, and the balance of it, pops up immediately.
>>>
>>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>>> Transactions associated with them appear to be public knowledge.
>>>
>>> Now I upgrade my wallet software and it says I now have a "reusable"
>>> address. My reaction is "Huh? Normal addresses are reusable, what's
>>> special about this weird reusable address thing that my buddy Bob's
>>> wallet software couldn't pay." I might even try to enter in a "reusable"
>>> address in blockchain.info, which won't work, and I'll just figure
>>> "must be some new unsupported thing" and move on with my life.
>>>
>>> On the other hand, suppose my wallet says I now have "stealth address"
>>> support. I'm going to think "Huh, stealth? I guess that means privacy
>>> right? I like privacy." If I try searching for a stealth address on
>>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>>> It said stealth addresses are private, so maybe the transactions are
>>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>>> in my browser? So like, there's no history being kept for others to
>>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>>> help, so I should learn more about that"
>>>
>>> Finally keep in mind that stealth addresses have had a tonne of very
>>> fast, and very wide reaching PR. The name is in the public conciousness
>>> already, and trying to change it now just because of vague bad
>>> associations is going to throw away the momentum of that good PR and
>>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>>> based on conversations there with people there, technical and
>>> non-technical, almost everyone had heard about them and almost everyone
>>> seemed to understand the basic idea of why they were a good thing. That
>>> just wouldn't have happened with a name that tried to hide what stealth
>>> addresses were for, and by changing the name now we risk people not
>>> making the connection when wallet software gets upgraded to support
>>> them.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>>
>>>
>>> --
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>>> Get a Quote or Start a Free Trial Today.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>> ___
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> --
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critica

Re: [Bitcoin-development] Stealth Addresses

[Natanael]

So far I've only liked the original name "Stealth address" and the
suggestion "routing address".

Should we put this up for some kind of informal vote with comments allowed?
Like a Google docs form?

- Sent from my phone
Den 17 jan 2014 10:18 skrev "Mike Hearn" :

> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
>
>https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak  wrote:
>
>> Peter I agree with you about  "reusable addresses", but aren't we also
>> trying to get away from the word "address" entirely?  How about calling it
>> a "payment key" or "reusable payment key" instead? using "stealth" is just
>> asking for bad press imo.
>>
>>
>> On 16 January 2014 21:28, Peter Todd  wrote:
>>
>>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>>> > Might I propose "reusable address".
>>> >
>>> > I think that describes it best to any non-programmer, and even more
>>> > so encourages wallets to present options as 'one time use' vs
>>> > 'reusable'.
>>> >
>>> > It definitely packs a marketing punch which could help drive
>>> > adoption. The feature is only useful if/when broadly adopted.
>>>
>>> I'm very against the name "reusable addresses" and strongly belive we
>>> should stick with the name stealth addresses.
>>>
>>> You gotta look at it from the perspective of a user; lets take standard
>>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>>> times as I want and everything works just great. I also can enter the
>>> address on blockchain.info's search box, and every transaction related
>>> to the address, and the balance of it, pops up immediately.
>>>
>>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>>> Transactions associated with them appear to be public knowledge.
>>>
>>> Now I upgrade my wallet software and it says I now have a "reusable"
>>> address. My reaction is "Huh? Normal addresses are reusable, what's
>>> special about this weird reusable address thing that my buddy Bob's
>>> wallet software couldn't pay." I might even try to enter in a "reusable"
>>> address in blockchain.info, which won't work, and I'll just figure
>>> "must be some new unsupported thing" and move on with my life.
>>>
>>> On the other hand, suppose my wallet says I now have "stealth address"
>>> support. I'm going to think "Huh, stealth? I guess that means privacy
>>> right? I like privacy." If I try searching for a stealth address on
>>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>>> It said stealth addresses are private, so maybe the transactions are
>>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>>> in my browser? So like, there's no history being kept for others to
>>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>>> help, so I should learn more about that"
>>>
>>> Finally keep in mind that stealth addresses have had a tonne of very
>>> fast, and very wide reaching PR. The name is in the public conciousness
>>> already, and trying to change it now just because of vague bad
>>> associations is going to throw away the momentum of that good PR and
>>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>>> based on conversations there with people there, technical and
>>> non-technical, almost everyone had heard about them and almost everyone
>>> seemed to understand the basic idea of why they were a good thing. That
>>> just wouldn't have happened with a name that tried to hide what stealth
>>> addresses were for, and by changing the name now we risk people not
>>> making the connection when wallet software gets upgraded to support
>>> them.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>>
>>>
>>> --
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>>> Get a Quote or Start a Free Trial Today.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>> ___
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> --
>> CenturyLin

Re: [Bitcoin-development] Stealth Addresses

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/17/2014 01:15 AM, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place
> to store our bikes. But, what colour should we paint it?
> 
> How about we split the difference and go with "privacy address"?
> As

Too close to private key, IMHO.

> Peter notes, that's what people actually like and want. The problem
> with stealth is it's got strong connotations with American military
> hardware and perhaps thieves sneaking around in the night:

And ninjas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS2PWHAAoJEAdzVfsmodw4QKoP/iCB62bthf+VyOAZFtP/LbU3
op//I06zOd6oj3zSM0B3Qwz0+H3L9OqWeo9yP1KzYb8YG7RelGf6KOh0LBQoo0bY
eEv8EqvJiW0JOi7gmMsaBgxtZ99TKibGVWMramAV+pSOkKbbbQ23O8a3Y2uopZIg
eypB9sUO9STTc/vwEKZRtefoXHWDUF8bXel/YfTGJQjOuxN/z6gsXRPp4xDvySL3
Ll3OvgEGrqIjIodvMZY+V5wzxj/TlU5kCKS6Vug/JEM1U0DmiBBikaR6Yus5m/fC
yyxEQH8jATLZVsAac4Z16rQXj1nTRh4w6X9KCTynEaba5Z8fz38habUNxyjT8JG+
cP+QDQac9Nnxuw6gzM4QRkOiQas5eVNRdzNJ48k2SGDLb7AYPBO/URAV8Cd05caY
Gx1ruC3MVGu7Fu1/9rtKeWMcNyAvpklzs9DhHfqNmYcRCl6NcoaCvxfq3NesI4Z9
uQrTfL9VBUXJJ2z8ZLe3ZAdBz46159JXCBKHIWwZ+fm0uPkelvoUo8oP+OdxwP1x
wGCYmfvuf8lSnud8WM5EDDGo4+7GUU5Pnh9p+o6Lyp4d0WoplUmSvz2XriiANQjq
z/Xo3B321sdLOEI/Nrqnn3S/hMveru7HO7xQx1aUATvYga4ZyFZh/Yp0bwOAESBZ
GoG0piwQbQhoQZMslV4T
=40o3
-END PGP SIGNATURE-

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[Mike Hearn]

I must say, this shed is mighty fine looking. It'd be a great place to
store our bikes. But, what colour should we paint it?

How about we split the difference and go with "privacy address"? As Peter
notes, that's what people actually like and want. The problem with stealth
is it's got strong connotations with American military hardware and perhaps
thieves sneaking around in the night:

   https://www.google.com/search?tbm=isch&q=stealth

But everyone loves privacy.


On Fri, Jan 17, 2014 at 8:49 AM, Drak  wrote:

> Peter I agree with you about  "reusable addresses", but aren't we also
> trying to get away from the word "address" entirely?  How about calling it
> a "payment key" or "reusable payment key" instead? using "stealth" is just
> asking for bad press imo.
>
>
> On 16 January 2014 21:28, Peter Todd  wrote:
>
>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>> > Might I propose "reusable address".
>> >
>> > I think that describes it best to any non-programmer, and even more
>> > so encourages wallets to present options as 'one time use' vs
>> > 'reusable'.
>> >
>> > It definitely packs a marketing punch which could help drive
>> > adoption. The feature is only useful if/when broadly adopted.
>>
>> I'm very against the name "reusable addresses" and strongly belive we
>> should stick with the name stealth addresses.
>>
>> You gotta look at it from the perspective of a user; lets take standard
>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>> times as I want and everything works just great. I also can enter the
>> address on blockchain.info's search box, and every transaction related
>> to the address, and the balance of it, pops up immediately.
>>
>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>> Transactions associated with them appear to be public knowledge.
>>
>> Now I upgrade my wallet software and it says I now have a "reusable"
>> address. My reaction is "Huh? Normal addresses are reusable, what's
>> special about this weird reusable address thing that my buddy Bob's
>> wallet software couldn't pay." I might even try to enter in a "reusable"
>> address in blockchain.info, which won't work, and I'll just figure
>> "must be some new unsupported thing" and move on with my life.
>>
>> On the other hand, suppose my wallet says I now have "stealth address"
>> support. I'm going to think "Huh, stealth? I guess that means privacy
>> right? I like privacy." If I try searching for a stealth address on
>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>> It said stealth addresses are private, so maybe the transactions are
>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>> in my browser? So like, there's no history being kept for others to
>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>> help, so I should learn more about that"
>>
>> Finally keep in mind that stealth addresses have had a tonne of very
>> fast, and very wide reaching PR. The name is in the public conciousness
>> already, and trying to change it now just because of vague bad
>> associations is going to throw away the momentum of that good PR and
>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>> based on conversations there with people there, technical and
>> non-technical, almost everyone had heard about them and almost everyone
>> seemed to understand the basic idea of why they were a good thing. That
>> just wouldn't have happened with a name that tried to hide what stealth
>> addresses were for, and by changing the name now we risk people not
>> making the connection when wallet software gets upgraded to support
>> them.
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>
>>
>> --
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> ___
> Bitcoin-dev