Re: [Bitcoin-development] Stealth Addresses

[Gary Rowe]

I like "reusable address".

It is very clear what the intended purpose is and gives a subtle hint that
other types of address should not be re-used.



On 16 January 2014 00:44, Eric Martindale  wrote:

> One variation of this, "recycled address", might avert misconceptions that
> the "re-use" is exclusive to one's own identity.
>
>
> Eric Martindale, relentless maker.
> http://www.ericmartindale.com
> +1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe
> *Note:* Beginning December 11th, 2013, I will only be intermittently
> available via email, SMS, and BitMessage.  As a courtesy, please leave a
> detailed message so that I can respond in kind.  Thanks!
>
>
> On Wed, Jan 15, 2014 at 7:05 PM, 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 think it meets all the criteria required:
>>
>>   - Communication between parties is a single message from the payee,
>> which may be public
>>   - Multiple payments to the same address are not publicly linkable on
>> the blockchain
>>   - The payee has explicitly designated they expect to receive more than
>> one payment at that address
>>   - Payer can publicly prove they made a payment to the reusable address
>> by revealing a secret
>>
>> I have high hopes for this feature. The war *against* address reuse may
>> soon be a distant memory.
>>
>> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik 
>> wrote:
>>
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>>
>> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell wrote:
>>
>>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport 
>>> wrote:
>>> > But may I suggest we consider changing the name "stealth address" to
>>> > something more neutral?
>>>
>>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>>> little cringe-worthy.
>>>
>>> "Private address" would be fine if not for confusion with private-keys.
>>>
>>> "Static address" is perhaps the best in my view. (also helps improve
>>>  awareness that normal addresses are intended to be more one-use-ness)
>>
>>
>>
>> --
>> 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
>
>
--
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] Tor / SPV

[Isidor Zeuner]

quote:
> > but then you remove the implication that a node has to give both public
> > and private IPs to a peer. If it's part of a batch of "addr"s, it could be
> > my own hidden service ID, but it could also be one that I learned from
> > someone else and is now propagating, for anyone to bootstrap with Tor
> > hidden service peers if they'd like.
> >
>
> Hmm. So you mean that we pick a set of peers we believe to not be sybils of
> each other, but they might give us hidden services run by other people? I
> need to think about that. If they're getting the hidden services just from
> addr announcements themselves, then you just punt the issue up a layer -
> what stops me generating 1 hidden service keys that all map to my same
> malicious node, announcing them, and then waiting for the traffic to
> arrive? If clearnet nodes inform of their own hidden service IDs, that
> issue is avoided.
>

Considering that the clearnet sybil protection also relies on scaling
up the resource requirements for an attacker, why not require hidden
service addresses following a certain pattern, like a fixed prefix?
Essentially also a PoW scheme...

> My goal here is not necessarily to hide P2P nodes - we still need lots of
> clearnet P2P nodes for the forseeable future no matter what.

What would you consider as the main merits of clearnet nodes?

Best regards,

Isidor

--
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] Tor / SPV

[Miron]

On Wed, 2014-01-15 at 20:29 -0800, Miron wrote:
> On Wed, 2014-01-15 at 23:51 +0100, Mike Hearn wrote:
> ...
> > 3) SPV wallets that want to get a good mix of nodes for measuring
> > pending transactions identify nodes on the clearnet via their addr
> > announcements+service flag, in the normal way. They select some of
> > these nodes using the standard clearnet anti-sybil heuristics and
> > connect without using Tor. They proceed to query them for their hidden
> 
> The SPV node could connect to the IP using Tor.  It would preserve the
> privacy of the SPV node - hard to see it's running Bitcoin.  It also
> reduces the ability of an attacker to MITM because the routing varies
> with each exit node.
> 

It would also be good to gossip the mapping of (IP -> onion address).
This would allow detection of a future MITM, since the MITM can't spoof
the onion fingerprint.



--
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] Tor / SPV

[Miron]

On Wed, 2014-01-15 at 23:51 +0100, Mike Hearn wrote:
...
> 3) SPV wallets that want to get a good mix of nodes for measuring
> pending transactions identify nodes on the clearnet via their addr
> announcements+service flag, in the normal way. They select some of
> these nodes using the standard clearnet anti-sybil heuristics and
> connect without using Tor. They proceed to query them for their hidden

The SPV node could connect to the IP using Tor.  It would preserve the
privacy of the SPV node - hard to see it's running Bitcoin.  It also
reduces the ability of an attacker to MITM because the routing varies
with each exit node.



--
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] Tor / SPV

[Miron]

On Wed, 2014-01-15 at 20:26 -0600, Brooks Boyd wrote:
> My goal here is not necessarily to hide P2P nodes - we still
> need lots of clearnet P2P nodes for the forseeable future no
> matter what. Rather we're just using hidden services as a way
> to get authentication and encryption. Actually the 6-hop
> hidden service circuits are overkill for this application, a
> 3-hop circuit would work just as well for most nodes that
> aren't Tor-exclusive. 
> 
> 
> 
...
> communication to Tor doesn't change that. I agree the six-hop circuits
> would be overkill for that; I wonder if the network slowdown you get

BTW, I believe that the number of hops can be reduced below 3 on both
sides (client/server).  For Orchid, this will require a change to
CircuitPathChooser.  For other Tor implementations, it might require
using the control port to custom-build a circuit.





--
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] Tor / SPV

[Brooks Boyd]

>
> My goal here is not necessarily to hide P2P nodes - we still need lots of
> clearnet P2P nodes for the forseeable future no matter what. Rather we're
> just using hidden services as a way to get authentication and encryption.
> Actually the 6-hop hidden service circuits are overkill for this
> application, a 3-hop circuit would work just as well for most nodes that
> aren't Tor-exclusive.
>

Ah, I see, so you're intending to use the Tor hidden services not for their
original purpose (hiding), but rather as as "authentication" (someone may
spoof my clearnet IP, but only I have the private key that makes this Tor
hidden service connect to me, so you can trust when you connect to it it's
really me). So if you trust the clearnet IP to be a friendly node, that
makes a more secure connection, but if you're already talking to a bad
node, moving the communication to Tor doesn't change that. I agree the
six-hop circuits would be overkill for that; I wonder if the network
slowdown you get on Tor will be worth the increased security? Yes, you'll
be more protected from MITM, but if this is widely adopted, would the
overall transactions/second the Bitcoin network could handle go down?

Brooks
--
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

[Eric Martindale]

One variation of this, "recycled address", might avert misconceptions that
the "re-use" is exclusive to one's own identity.


Eric Martindale, relentless maker.
http://www.ericmartindale.com
+1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe
*Note:* Beginning December 11th, 2013, I will only be intermittently
available via email, SMS, and BitMessage.  As a courtesy, please leave a
detailed message so that I can respond in kind.  Thanks!


On Wed, Jan 15, 2014 at 7:05 PM, 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 think it meets all the criteria required:
>
>   - Communication between parties is a single message from the payee,
> which may be public
>   - Multiple payments to the same address are not publicly linkable on the
> blockchain
>   - The payee has explicitly designated they expect to receive more than
> one payment at that address
>   - Payer can publicly prove they made a payment to the reusable address
> by revealing a secret
>
> I have high hopes for this feature. The war *against* address reuse may
> soon be a distant memory.
>
> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik 
> wrote:
>
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell wrote:
>
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport 
>> wrote:
>> > But may I suggest we consider changing the name "stealth address" to
>> > something more neutral?
>>
>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>>  awareness that normal addresses are intended to be more one-use-ness)
>
>
>
> --
> 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] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Gregory Maxwell]

On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman  wrote:
> Choosing how many bits to put in the prefix may be difficult, particularly
> if transaction load changes dramatically over time. 0 or 1 bits may be
> just fine for a single user running their own node, whereas a central
> service might want 4 or 5 bits to keep their computation costs scalable.

Ignoring prefixes the cost for each reusable address is only a small
percentage of the full node cost (rational: each transaction has one
or more ECDSA signatures, and the derivation is no more expensive), so
I would only expect computation to be an issue for large centralized
services. (non-full nodes suffer more from just the bandwidth impact).

I'd point out that regardless of how long the desired prefix is, the
encoded prefix should probably always be constant length in all
reusable addresses. If you don't want a particular prefix then the
sender should just pick random data for the rest of the space. There
is no need to publish any additional distinguishing data in the form
of how long the prefix is.

--
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] Bait for reusable addresses

[Gregory Maxwell]

One challenge with reusable addresses is that while they result in a
small constant overhead for full nodes in searching for their own
transactions they create large overheads for SPV nodes.

One way to address this is for the SPV nodes to hand their servers
their blinding private key so that the server may test addresses on
their behalf. The primary problem with this is that it is
non-reputable:  If I show you a blinding private key and say a set of
transactions are related you will be utterly convinced of it, the
transactions really are related. This makes the privacy brittle.

It also has a downside of not being indexable for the server, the
server must do O(clients * reusable-address-txn) work and the work
includes an ECC multiply.

An idea that Adam Back had originally proposed was including optional
"bloom bait", a small token— say 8 bits— that distinguished
transactions which allowed an anonymity set vs filtering trade off.
Such a bait would be indexable, enabling faster lookup too.

But bloom bait has privacy problems more severe than the current SPV
bloom filtering. While you leak information to your SPV servers today
if you use bloom filtering the leak usually goes no further. So a
compromise requires both a statistical attack _and_ using SPV servers
that log data against your interest.  With bloom bait the whole
network can see the relation. That is unfortunate.

I suggest instead that with optional bait is included in an address
that the sender compute H(nonce-pubkey) and then pick one byte at
random out of the first 16 and xor it with the specified bait and
store the result in the transaction.  An SPV server can now index the
bait as it comes in by extracting 16 8-bit keys from each transaction
(the 16 bytes xored with the bait in the transaction).  When the
client wants to search for transactions it can give the server a list
of keys its interested in— including their real key and number of
random number of cover keys.

ObTechnicalWank:  This is a specific simple instance of a general
class of solutions which are related to locally decodable error
correcting codes: E.g. the transaction data represents a codeword in a
vector-space and the degree of freedom provided by the adjustable
prefix is used to ensure that codeword is never more than a certain
distance from a specified point.  The point isn't made public in the
transaction and it's hidden from the server by providing several
points.   There is still an information leak here— as if someone
believes a set of transactions are related they can intersect their
radiuses and test if the intersection is empty, and if it's not assume
that they found the secret bait— but it is substantially lower an
information leak than the prefix case.

I didn't give any though into the parameters 8-bits and 16 dimensions.
Some reasoning should be done to fix the parameters in order to make
them the most useful: e.g.

Systems derived from more complex linear codes might give better
performance, e.g. two secret bloom baits, two prefixes in the
transaction bait0^random_char[0-8], bait1^random_char[0-8],  server
extracts 16 keys.. and returns to the client transactions which have
at least two key matches with their list.

Obviously whatever is used needs to be easy to implement, but schemes
loosely based on fountain codes should only require picking some
things and xoring... so they should be simple enough.

--
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

[Odinn Cyberguerrilla]

Yes. Good idea(s).

> 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 think it meets all the criteria required:
>
>- Communication between parties is a single message from the payee,
> which may be public
>- Multiple payments to the same address are not publicly linkable on
> the
> blockchain
>- The payee has explicitly designated they expect to receive more than
> one payment at that address
>- Payer can publicly prove they made a payment to the reusable address
> by revealing a secret
>
> I have high hopes for this feature. The war *against* address reuse may
> soon be a distant memory.
>
> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik 
> wrote:
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>>
>> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell 
>> wrote:
>>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
>>>  wrote:
 But may I suggest we consider changing the name "stealth address" to
 something more neutral?
>>>
>>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>>> little cringe-worthy.
>>>
>>> "Private address" would be fine if not for confusion with private-keys.
>>>
>>> "Static address" is perhaps the best in my view. (also helps improve
>>> awareness that normal addresses are intended to be more
>>> one-use-ness)--
> 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] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Jeremy Spilman]

On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back  wrote:
> I was meaning to comment on the SPV privacy properties.
>
> For full-node use these unlinkable static addresses have quite nice
> properties.  It also nicely solves the problem of having to educate users
> and wallet authors to not reuse addresses.  But for SPV nodes they have  
> no direct-way to find the payments.  So then in Peter Todd's variant  
> (maybe it was suggested by Greg Maxwell?) there is a second address so  
> that the SPV
> client can delegate detection to a full node without giving it the  
> private key allowing it to spend!  (This is something analogous to bloom  
> filtering).

The second pubKey is useful for delegating scanning, or even just being  
able to scan for transactions yourself without keeping bitcoin-encumbered  
private keys decrypted in memory. So even while running your own full node  
there are good reasons to use a second pubKey to derive the shared secret.

> But I think its moderately expensive for the full node because it has to  
> do a DH calculation per transaction and its not precomputable so there  
> is IO
> per query.  (In the P version in fact only payments which are thereby
> reconizable as unlinkable static need to be processed).

And of course, if you have multiple reuseable addresses, then you're doing  
this calculation separately to check each one.

So the load on a popular centralized service would be quite high, which  
you may consider a feature.

>
> Then an artificial prefix is proposed to constrain the query to a subset,
> however that leaks to everyone so in some ways its a worse privacy leak
> than bloom filtering.  It can be used to rule out recipients and could be
> quite a powerful extra lever for statistical analysis.

Choosing how many bits to put in the prefix may be difficult, particularly  
if transaction load changes dramatically over time. 0 or 1 bits may be  
just fine for a single user running their own node, whereas a central  
service might want 4 or 5 bits to keep their computation costs scalable.

But I think it's great people can choose how to trade privacy for  
computation/bandwidth however they want, and services can compete to offer  
monitoring for 0+ bit prefixes.

> (And also there is proposed a version of the prefix computed via
> brute-force to make it somewhat stealthy still).

I think in this case the hash grinding of the prefix would only being used  
if thats how transactions are being indexed. I don't think it adds any  
privacy, it's just added work we're forced to do in order for the prefix  
to work as designed. Peter, please correct me if I'm wrong.


>
> Maybe in the payment address case the service should choose the  
> derivation factor and communicate it and the client with the static
> address, as suggested by Alan Reiner because then it can also serve
> the function of allowing the service to tie the payment to the users
> account.

I think any change which requires more than a single published public  
message (e.g. a posting in a forum, or in a README.me in Github) should be  
seen as solving an entirely different problem.

If you have directed communication from payee->payer, I think there's  
simply no reason to do it this way. (By "this way" I mean ECDH with  
OP_RETURN P).

We could try to define a different reusable address type, for when you can  
make a single directed message from payer->payee, and in that case there's  
probably no need for ECDH or the prefix, like Alan's proposal.

But once you admit having that directed communication, then you are  
swimming very close to the payment protocol.


--
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

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/15/2014 04:05 PM, Jeremy Spilman wrote:
> Might I propose "reusable address".

Say it like it is. This is the only suggestion so far that I really like.

No amount of finger wagging got people to stop using the block chain
for data storage, but news of the OP_RETURN change to relay rules in
0.9 got people to at least be less damaging in how they do it.

Having an officially named "reusable address" format won't stop people
from doing dumb things (e.g. vanity addresses), but at least maybe
they'll stop using traditional addresses for it.

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

iQIcBAEBAgAGBQJS1yafAAoJEAdzVfsmodw40ccQAI0EFAyODzx7yXvlq9idctSd
xisH4xsOMlsW4lV7xReMnhQsCZ5A+qTMcCd7n7a0bveAxWg1srqBDONLXtHZfwiN
Px/TfoJKPt1oIHnCoyN8G6pcuHhbUbL3lV19sH02dGnM9Ystf9F4oeqwDTITYb5i
huqShMfaTdLEig76zPCLQcOT88deIWZgIxc3R4Do4aCDoyh//2LVZKfzQyEJzVms
njgxcVLVRlomofPW+a+60zm/iLsrbmDjwvWSH8IB4d5ik1aO3732pWgNz3X4HSLk
1s9hVEnpN3GLIWmCcPkbrE9RZtcitghjwrt/xOMKQaqprUuFW4COc0fsfzdLIRtP
bhrA/dnhVSxiUnjc7gLJBnB9+udVKdk2aTdJvSMB1PvhW9QKPjU/H4AW/yQYmism
rSr9imurbi3WosTewtwdcQD47SNS4ALMh//3MeHWOBUMEHP7Tki6i8qR+/xOK+vx
zMc4dnnTQsbgu9bKhrU7ia4eoe/UDvPoLck5cb2+PwYTInfdYBWn1ivbHO7S5ppP
R+/Tc8h3TyLLcPQmH0tpSX+C/YwvctiGsd+iXBRfSTe7o+0wLn8NcDNGi7QI0ipQ
iCHJup9K0FJqf9OuH9qYeaWht7cyuRJ5H4P/HNESGZaPSdTHDpStSmAzdtbBZOkI
qrFg7irL2+CxXwI4H6vC
=XEtz
-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

[Gregory Maxwell]

On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman  wrote:
> Might I propose "reusable address".

I like this too.

--
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] Tor / SPV

[Robert McKay]

On Wed, 15 Jan 2014 23:51:21 +0100, Mike Hearn wrote:
> The goal of all that is that we get to keep our existing IPv4 based
> anti-sybil heuristics, so we can’t possibly make anything worse,
> only better. Plus, we’ve now set things up so in future if/when we
> come up with a better anti-sybil system based on anonymous identities
> or other fancy crypto, we can take out the “connect via clearnet”
> step and go straight to using hidden services with only a very small
> set of code changes and no new protocol work.

I think it might be ok to use proof-of-stake on as an anti-sybil scheme 
on tor.. people would obviously not want to associate their wallet with 
their IP address, but is there any harm in associating it with a 
(temporary) tor service id (especially one that isn't used for anything 
other than relaying bitcoin transactions)? If each node you connect too 
can sign some challenge with a key that controls some BTC (and your 
client node verifies that the funds are different) then that might be 
useful.. even if it were only a small 0.01BTC stake that would be 
similar to the cost of obtaining another IP through a cheap VPS or VPN 
and significantly higher than the cost to an attacker who is able to 
MITM everything and operate on any IP anyway.

Rob

--
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

[Jeremy Spilman]

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 think it meets all the criteria required:  - Communication between parties is a single message from the payee, which may be public  - Multiple payments to the same address are not publicly linkable on the blockchain  - The payee has explicitly designated they expect to receive more than one payment at that address  - Payer can publicly prove they made a payment to the reusable address by revealing a secretI have high hopes for this feature. The war *against* address reuse may soon be a distant memory.On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik  wrote:"static address" seems like a reasonable attempt at describing intended use/direction.On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell  wrote:
On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport  wrote:

> But may I suggest we consider changing the name "stealth address" to
> something more neutral?

ACK.  Regardless of the 'political' overtones, I think stealth is a
little cringe-worthy.

"Private address" would be fine if not for confusion with private-keys.

"Static address" is perhaps the best in my view. (also helps improve awareness that normal addresses are intended to be more one-use-ness)--
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] Tor / SPV

[Mike Hearn]

>
> May need to modify the network address format to include the ability to
> differentiate IPv6 clearnet vs. Tor addresses
>

sipa already implemented some clever hack where the 80-bit Tor keys are
mapped to a subregion of reserved IPv6 space, giving magical IPv6 hidden
service addresses. So addr packets can and do already contain onion
addresses.


> but then you remove the implication that a node has to give both public
> and private IPs to a peer. If it's part of a batch of "addr"s, it could be
> my own hidden service ID, but it could also be one that I learned from
> someone else and is now propagating, for anyone to bootstrap with Tor
> hidden service peers if they'd like.
>

Hmm. So you mean that we pick a set of peers we believe to not be sybils of
each other, but they might give us hidden services run by other people? I
need to think about that. If they're getting the hidden services just from
addr announcements themselves, then you just punt the issue up a layer -
what stops me generating 1 hidden service keys that all map to my same
malicious node, announcing them, and then waiting for the traffic to
arrive? If clearnet nodes inform of their own hidden service IDs, that
issue is avoided.

My goal here is not necessarily to hide P2P nodes - we still need lots of
clearnet P2P nodes for the forseeable future no matter what. Rather we're
just using hidden services as a way to get authentication and encryption.
Actually the 6-hop hidden service circuits are overkill for this
application, a 3-hop circuit would work just as well for most nodes that
aren't Tor-exclusive.
--
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] Tor / SPV

[Brooks Boyd]

>
> 2) Secondly, we bump the protocol version, add a service flag and
> introduce a new P2P protocol command “tor?”. If a client sends a tor?
> message to a node that has the new service flag set, it will respond with a
> new “tor” message that contains a regular addr packet, with a single
> address, the IPv6-ified version of its hidden service name.
>


Rather than a separate message type that implies binding a clearnet IP to a
hidden service ID, why not add the service flag that the peer would like
Tor addresses, and the remote peer can then add IPv6-ified hidden service
addresses to "addr" messages? May need to modify the network address format
to include the ability to differentiate IPv6 clearnet vs. Tor addresses,
but then you remove the implication that a node has to give both public and
private IPs to a peer. If it's part of a batch of "addr"s, it could be my
own hidden service ID, but it could also be one that I learned from someone
else and is now propagating, for anyone to bootstrap with Tor hidden
service peers if they'd like.

Brooks
--
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

[Roy Badami]

On Wed, Jan 15, 2014 at 11:17:33PM +, I wrote:
> How about just calling them 'type S addresses'?

(Assuming they're encoded in such as way that they actually start with 's'.
Otherwise whatever prefix is actually used, obviously.)

--
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

[Roy Badami]

How about just calling them 'type S addresses'?

Not sure any other name will in reality convey much more meaning than
that.

On Wed, Jan 15, 2014 at 06:07:28PM -0500, Jeff Garzik wrote:
> "Routing address" is pretty good too.  Unsure whether the synergy and
> familiarity with bank routing numbers improves the situation, or
> not...
> 
> 
> On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami  wrote:
> > On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> >> "static address" seems like a reasonable attempt at describing intended
> >> use/direction.
> >
> > ...as opposed to an address configured by DHCP?
> >
> > More seriously, I don't think a typical user will understand anything from
> > the phrase "static address".  But it is a neutral name, and it is shorter
> > than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
> >
> > -roy
> 
> 
> 
> -- 
> 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

[Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)

[Adam Back]

So I like static address name too.  In the write up for my variant I called
it something less sexy than stealth "unlinkable public address":

https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530

(there are 3 variants that are approximately the same thing).

Maybe we could call it an unlinkable static address.  Otherwise static
addresses are maybe too synonymous with reused addresses a bad practice we
have been complaining about users and wallet authors incorrectly doing.

But to explain, in Peter Todds (and Amir Taaki also?) variant stealth refers
to an actual useful security criteria.  Stealth objective actually means
"looks like a normal bitcoin payment to the outside observer".  You
generally want that to be the case for fungibility reasons.  Its like
browser cookie state, the more things that are unusual about your
transaction, the more your transactions identify you in the public
block-chain.  Statistics are cumulative so it matters.


And is an actual element of stealthiness (hence the name) in this variant
that Peter Todd proposed, at least as an objective, though I think the
stealthiness somewhat fails because the P parameter is extra and not present
in a normal transaction.

Unfortunately so far removing P and using an input in its stead breaks
CoinJoin which is also necessary for fungibility.  Maybe there is another
way to make an extended CoinJoin that can mix inputs and unlinkable static
addresses.


I was meaning to comment on the SPV privacy properties.

For full-node use these unlinkable static addresses have quite nice
properties.  It also nicely solves the problem of having to educate users
and wallet authors to not reuse addresses.  But for SPV nodes they have no
direct-way to find the payments.  So then in Peter Todd's variant (maybe it
was suggested by Greg Maxwell?) there is a second address so that the SPV
client can delegate detection to a full node without giving it the private
key allowing it to spend!  (This is something analogous to bloom filtering). 
But I think its moderately expensive for the full node because it has to do
a DH calculation per transaction and its not precomputable so there is IO
per query.  (In the P version in fact only payments which are thereby
reconizable as unlinkable static need to be processed).

Then an artificial prefix is proposed to constrain the query to a subset,
however that leaks to everyone so in some wayts its a worse privacy leak
than bloom filtering.  It can be used to rule out recipients and could be
quite a powerful extra lever for statistical analysis.  (And also there is
proposed a version of the prefix computed via brute-force to make it
somewhat stealthy still).


So I also am quite enthusiastic about the possiblity to fix this address
reuse problem, but there remain a few open problems in my view, for SPV
uses.  Not nay-saying, I spent quite a bit of time trying to solve this for
my variant, its a tricky problem, or basically we wouldnt have one-use
addresses and bloom filtering.


But maybe its intereting enough already for full-node uses.  Many processors
and businesses are full nodes.  Many power users run full-nodes  The data
isnt lost, you just need to scan a full-node.

It could help the related problem of paying the wrong person.  Ie deposit
address given by merchant.  If the deposit address is static, and the used
address user derived from it, then that itself is an assurance to the user
that they are paying an address at least owned by the service.  (As opposed
to someone who hacked the web site or MITM the link).  Of course for users
probably the main likelihood is they have malware on their machine, but that
is what offline wallets are for.  A smartphone is maybe a little less
hackable and could be trained to store the static address and warn if its
not the same as the last time they used the site.  (TOFU for bitcoin
addresses, or at least be able to call someone you know who also uses the
service and compare static addresses).

Maybe in the payment address case the service should choose the derivation
factor and communicate it and the client with the static address, as
suggeste by Alan Reiner because then it can also serve the function of
allowing the service to tie the payment to the users account.

People also mention payment protocol for certifying addresses however I
think it is useful to have address level TOFU / static to principal
verification because it is simpler for harware wallets, maps to account
number concept users understand, and doesnt rely on the CA infrastructure. 
Also the typical payment protcol is talking about a message constructed by a
web app.  Thats millions of lines of web server, script language, db code
etc in play on an online server.  The static address private key would be
airgapped from that mess.  

Mike Hearn proposed if I understand that you could something analogous and
upload in batches signed payment protocol sub-messages from a different CA
certificate key.  But I thi

Re: [Bitcoin-development] Stealth Addresses

[Jeff Garzik]

"Routing address" is pretty good too.  Unsure whether the synergy and
familiarity with bank routing numbers improves the situation, or
not...


On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami  wrote:
> On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>
> ...as opposed to an address configured by DHCP?
>
> More seriously, I don't think a typical user will understand anything from
> the phrase "static address".  But it is a neutral name, and it is shorter
> than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
>
> -roy



-- 
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

[Roy Badami]

On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.

...as opposed to an address configured by DHCP?

More seriously, I don't think a typical user will understand anything from
the phrase "static address".  But it is a neutral name, and it is shorter
than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)

-roy

--
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]

Do any people who aren't computer programmers or physicists ever use the
term "static"?

I liked routing address.


On Wed, Jan 15, 2014 at 9:44 PM, Jeff Garzik  wrote:

> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
>
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell wrote:
>
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport 
>> wrote:
>> > But may I suggest we consider changing the name "stealth address" to
>> > something more neutral?
>>
>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>> awareness that normal addresses are intended to be more one-use-ness)
>>
>>
>> --
>> 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
>
>
--
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] Tor / SPV

[Mike Hearn]

intro text starts here, protocol upgrade proposal starts further down

Recently on IRC we have discussed what it'd take to use SSL on P2P connections, 
the goal being encryption and authentication of traffic to help avoid passive 
wiretapping and sybil attacks.

Gregory pointed out - very reasonably - that OpenSSL is huge and very 
old-school C, meaning that using it to implement SSL would put a big piece of 
code exposed to the internet into the same process as people’s wallets. This 
would be not excellent. Also, even with encryption, with SSL you only get some 
resistance to traffic analysis. And it'd be a complicated upgrade.

Tor is an option, but it has other disadvantages:

1) Also a giant piece of C that is likely to contain bugs
2) Breaks our anti-sybil heuristics when connecting to hidden services
3) MITM very likely when not connecting to hidden services
4) Is not usable as a library at all. Convention to use Tor is "tell user to 
start TorBrowser and connect to the SOCKS port".

The latter point means in reality hardly anyone will ever connect via Tor, as 
you'd have to do extra setup and most people are lazy. Especially it's not 
going to work on mobile. It’s not worth doing something complicated if hardly 
anyone would use it.

But recently I discovered this interesting piece of code:

   http://www.subgraph.com/orchid.html

It is a pure Java implementation of the Tor protocol (client only, no relays), 
easily usable as a library. Sure enough after about an hour of fiddling around, 
I now have a bitcoinj that connects via Tor with no other software running.

Suddenly making MultiBit, the Android Bitcoin Wallet app, Hive and other 
bitcoinj based wallets use Tor by default seems very plausible.

So I started thinking about what it'd take to switch this on for everyone. The 
biggest problem is that SPV wallets can't verify unconfirmed/pending 
transactions for themselves, so they rely on counting the number of peers that 
announced it and assuming that their internet connections aren't being tampered 
with. Mostly this assumption is a good one - we have never heard anyone report 
that they were paid with a fake pending tx using a MITM attack.

However, with Tor the chance of being MITMd goes up dramatically. Lots of 
people have reported exit nodes that are doing SSL stripping. Being sybilled 
when using exit nodes seems rather likely.

Connecting to hidden services solve the MITM problem but screws you in a 
different way. Bitcoin Core has some weak heuristics in the code to try and 
ensure we don’t accidentally connect to nodes all controlled by the same guys … 
mostly by trying to keep a good mix of /16s. This is probably not very hard to 
defeat, but it does at least raise the bar beyond “buy lots of amazon VMs”. 
With hidden services we lose that. Also, there aren’t very many nodes running 
as hidden services - if all bitcoinjs started hitting them simultaneously 
they’d probably die.

tl;dr the proposal starts here

Let’s fix this so SPV wallets can use Tor by default. Downgrading things is not 
an option, it must be pure upgrade. We can do it like this:

1) Firstly, we observe that MITM only matters when we’re trying to count 
pending transaction announcements, but most of the load SPV wallets impose on 
the network is chain filtering. So it’s OK to download the chain from any 
arbitrary clearnet IP via Tor because we’re checking Merkle branches.  This 
ensures we won’t put excessive load on hidden service nodes.

2) Secondly, we bump the protocol version, add a service flag and introduce a 
new P2P protocol command “tor?”. If a client sends a tor? message to a node 
that has the new service flag set, it will respond with a new “tor” message 
that contains a regular addr packet, with a single address, the IPv6-ified 
version of its hidden service name.

3) SPV wallets that want to get a good mix of nodes for measuring pending 
transactions identify nodes on the clearnet via their addr 
announcements+service flag, in the normal way. They select some of these nodes 
using the standard clearnet anti-sybil heuristics and connect without using 
Tor. They proceed to query them for their hidden service key. After they’ve 
done that, they record the public IP->hidden service mapping and can go ahead 
and connect back to them at any later time via Tor itself.

This would seem to be pointless - did we not just go ahead and bypass Tor 
entirely, thus making neither node hidden? Is it not a dead cert that the next 
connection the node gets via Tor is likely the same computer? Yes, but it only 
matters the first time. As long as those nodes are somewhat stable the mapping 
will be recorded on disk and the next time the wallet starts, it’ll skip 
straight to using Tor.

The goal of all that is that we get to keep our existing IPv4 based anti-sybil 
heuristics, so we can’t possibly make anything worse, only better. Plus, we’ve 
now set things up so in future if/when we come up with a better anti-sybil 

[Bitcoin-development] Static addresses on chains encouraging address *RE* use

[Troy Benjegerdes]

Let's suppose I have an alternate blockchain that specifically encourages
address *RE* use, and charges those that desire privacy higher transaction
fees to cover the network cost in computation and storage.

Does the static address privacy system still work, or does it fall apart
because 95% of the transactions re-use addresses, making them 'effectively 
static', just like my DHCP IP that has not changed as long as I've used it?


On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
> 
> 
> 
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell  wrote:
> 
> > On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport 
> > wrote:
> > > But may I suggest we consider changing the name "stealth address" to
> > > something more neutral?
> >
> > ACK.  Regardless of the 'political' overtones, I think stealth is a
> > little cringe-worthy.
> >
> > "Private address" would be fine if not for confusion with private-keys.
> >
> > "Static address" is perhaps the best in my view. (also helps improve
> > awareness that normal addresses are intended to be more one-use-ness)
> >


--
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

[Jeff Garzik]

"static address" seems like a reasonable attempt at describing intended
use/direction.



On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell  wrote:

> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport 
> wrote:
> > But may I suggest we consider changing the name "stealth address" to
> > something more neutral?
>
> ACK.  Regardless of the 'political' overtones, I think stealth is a
> little cringe-worthy.
>
> "Private address" would be fine if not for confusion with private-keys.
>
> "Static address" is perhaps the best in my view. (also helps improve
> awareness that normal addresses are intended to be more one-use-ness)
>
>
> --
> 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

[Gregory Maxwell]

On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport  wrote:
> But may I suggest we consider changing the name "stealth address" to
> something more neutral?

ACK.  Regardless of the 'political' overtones, I think stealth is a
little cringe-worthy.

"Private address" would be fine if not for confusion with private-keys.

"Static address" is perhaps the best in my view. (also helps improve
awareness that normal addresses are intended to be more one-use-ness)

--
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

[Ben Davenport]

Love what's happening here, and how quickly things are moving, from initial
concept, to first implementation, to first transaction.

But may I suggest we consider changing the name "stealth address" to
something more neutral?

Already, many people on Reddit and elsewhere are misinterpreting the
purpose of such addresses, whether for tax evasion, criminal activity, or
who knows what. Bitcoin already has plenty of political hurdles based
sheerly on the technology. We don't need to make life harder for ourselves.
Even forgetting about politics, the "stealth" association just seems to
imply something secretive going on. Is a Fortune 500 company or worldwide
charity going to want to use something called a "stealth address"?

I'd propose the alternate term "routing address".

- It's a descriptive, neutral term
- It accurately describes what the address is: it's a way to route payment
to a recipient, but not the actual final address
- It can be analogized to a bank's routing number: It is uniquely, publicly
and persistently tied to the receiving institution. The payor and payee
knows when payment is made using it, but it's not publicly visible.

That's the best I've got, but here are some alternate terms in case that
doesn't work:

- reusable public address
- permanent public address
- permanent address
- static address

I don't like these quite as much because they're not as clear. Normal
addresses are all reusable, permanent and static -- they just _shouldn't_
be used that way.

Ben


On Tue, Jan 14, 2014 at 4:19 PM, Drak  wrote:

> Sorry this is possibly OT, but someone posted this thread to r/bitcoin and
> it's gone straight to position 1. People are really enthusiastic about this
> feature.
>
> Drak
>
>
> --
> 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