[Bitcoin-development] Reconsidering github

[Jeff Garzik]

It would be nice if the issues and git repo for Bitcoin Core were not
on such a centralized service as github, nice and convenient as it is.

To that end, I note that Linux does its own git repo, and now requires
2FA: 
http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication

As a first step, one possibility is putting the primary repo on
bitcoin.org somewhere, and simply mirroring that to github for each
push.

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

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reconsidering github

[Dāvis Mosāns]

There's actually a pretty good alternative - GitLab
https://about.gitlab.com/ it's open source, self-hosted and provides
similar features to GitHub


2014-08-19 15:02 GMT+03:00 Jeff Garzik jgar...@bitpay.com:

 It would be nice if the issues and git repo for Bitcoin Core were not
 on such a centralized service as github, nice and convenient as it is.

 To that end, I note that Linux does its own git repo, and now requires
 2FA:
 http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication

 As a first step, one possibility is putting the primary repo on
 bitcoin.org somewhere, and simply mirroring that to github for each
 push.

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


 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reconsidering github

[Wladimir]

On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik jgar...@bitpay.com wrote:
 It would be nice if the issues and git repo for Bitcoin Core were not
 on such a centralized service as github, nice and convenient as it is.

Despite my complaining about github, I don't like the idea of moving
somewhere else. The current way of working - to use github for storing
the tree, and use a custom script for signing+merging - is fine with
me.

Github has a low barrier to contribution. Almost every open source
developer already has a github account. Switching to something
self-hosted makes it more difficult for people to contribute.

Plus if we have to take the hosting upon ourselves, we have to handle
sysadmin work ourselves as well. That's not a good use of the limited
manpower available.

Also it will be a lot of work to migrate over all the current issues
and pulls. I don't look forward to that. I don't see the point of
this, sorry.

Wladimir

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Raúl Martínez]

Only messages between peers are encrypted, only during transit.

Before sending a transaction to Node B you use his public key, so Node B
has the key
El 19/08/2014 17:05, Richard Moore m...@ricmoo.com escribió:

 If you encrypt all messages with an asymmetric cipher, how would each node
 make use of the blockchain in an encrypted form? Each node would be able to
 encrypt the data, but only the Bitcoin Core Dev could decrypt it?


 On Aug 19, 2014, at 5:49 AM, Raúl Martínez r...@i-rme.es wrote:

 Hi,
 I believe that all comunications should be encrypted by default, no matter
 that is public information (tx info), the only exception I would make would
 be block packets (to avoid increasing propagation time).

 I suggest that Bitcoin Core should generate a public/private key pair and
 share the public one with peers.

 This could provide privacy and integrity but not autentication.

 This way you can impersonate a bitcoin node (active mitm) but you cant
 just be passive and record all transactions send or recieved by an IP
 address.

 Today you can just watch for incoming/outgoing transactions to determine
 what tx are created in the Node, when you find one you can see the Bitcoin
 address inputs and outputs and track that person's bitcoins.

 As an example, SSH provides this kind of encryption, althogh Bitcoin Core
 should ignore fingerprint changes (caused due to reinstalls).

 Please feel free to disqus why this is not needed or why you like this
 idea.

 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


 .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º

 Richard Moore ~ Founder
 Genetic Mistakes Software inc.
 phone: (778) 882-6125
 email: ric...@geneticmistakes.com
 www: http://GeneticMistakes.com


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reconsidering github

[Bryan Bishop]

On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik jgar...@bitpay.com wrote:
 As a first step, one possibility is putting the primary repo on
 bitcoin.org somewhere, and simply mirroring that to github for each
 push.

Smaller first step would be to mirror the git repository on
bitcoin.org, which is necessary anyway before switching primaries.

- Bryan
http://heybryan.org/
1 512 203 0507

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Richard Moore]

Oh, I see. I misread, thinking you wanted the dev team to have a private key 
and share the public key, similar to alerts. But each peer would have a 
public/private key pair and use something akin to ECDH for a symmetric key and 
transport using a block cipher?

How would you share the public key? If I were a man-in-the-middle, I could 
intercept the public key, generate my own and pass that along and then decouple 
the pipe when the other side shares their public key.

Also, you should not ignore your SSH fingerprint, as you exactly open yourself 
to mitm attacks.



On Aug 19, 2014, at 11:11 AM, Raúl Martínez r...@i-rme.es wrote:

 Only messages between peers are encrypted, only during transit.
 
 Before sending a transaction to Node B you use his public key, so Node B has 
 the key
 
 El 19/08/2014 17:05, Richard Moore m...@ricmoo.com escribió:
 If you encrypt all messages with an asymmetric cipher, how would each node 
 make use of the blockchain in an encrypted form? Each node would be able to 
 encrypt the data, but only the Bitcoin Core Dev could decrypt it?
 
 
 On Aug 19, 2014, at 5:49 AM, Raúl Martínez r...@i-rme.es wrote:
 
 Hi,
 I believe that all comunications should be encrypted by default, no matter 
 that is public information (tx info), the only exception I would make would 
 be block packets (to avoid increasing propagation time).
 
 I suggest that Bitcoin Core should generate a public/private key pair and 
 share the public one with peers.
 
 This could provide privacy and integrity but not autentication.
 
 This way you can impersonate a bitcoin node (active mitm) but you cant just 
 be passive and record all transactions send or recieved by an IP address.
 
 Today you can just watch for incoming/outgoing transactions to determine 
 what tx are created in the Node, when you find one you can see the Bitcoin 
 address inputs and outputs and track that person's bitcoins.
 As an example, SSH provides this kind of encryption, althogh Bitcoin Core 
 should ignore fingerprint changes (caused due to reinstalls).
 
 Please feel free to disqus why this is not needed or why you like this idea.
 
 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º
 
 Richard Moore ~ Founder
 Genetic Mistakes Software inc.
 phone: (778) 882-6125
 email: ric...@geneticmistakes.com
 www: http://GeneticMistakes.com
 

.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º

Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ric...@geneticmistakes.com
www: http://GeneticMistakes.com

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/19/2014 03:30 PM, Richard Moore wrote:
 Oh, I see. I misread, thinking you wanted the dev team to have a
 private key and share the public key, similar to alerts. But each
 peer would have a public/private key pair and use something akin to
 ECDH for a symmetric key and transport using a block cipher?
 
 How would you share the public key? If I were a man-in-the-middle,
 I could intercept the public key, generate my own and pass that
 along and then decouple the pipe when the other side shares their
 public key.
 
 Also, you should not ignore your SSH fingerprint, as you exactly
 open yourself to mitm attacks.

http://curvecp.org

If that's not acceptable, even using TLS with self-signed certificates
would be an improvement.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJT83Y1AAoJEMP3uyY4RQ21aqUH/3rGvgz3J6UYY2Qb2qzNoucB
QqIj4fByZncX7Fhx5YK6fc6QoLr4Oqxd+zgbJ3ghrLtAJ7dm61iLmmib8MuDz2K1
kQj8xmZhWuUFI26bjK54RlKoWg46XFKNKcaVub6JmVg9dH8mX86mF746KnR5ZqdX
BuehWoEqcHlY3JkrTgOGpHjT/EGScZQxzJHzsBOfUJuX12lFtzcWzBTZyo5K8fD+
6eub3i6Fc4qn/c788UVFsmHeWV+NCeB1/y94V1+peIPWYhrZO+FVm+xEflG4U81Q
MRejqNjFT8ztT5vRHx1qJsmIgnzT0SXfh+FRt0hdqJizjlmyntMmCXjFmtnIeT8=
=9qWl
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Gregory Maxwell]

On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
justusranv...@riseup.net wrote:
 If that's not acceptable, even using TLS with self-signed certificates
 would be an improvement.

TLS is a huge complex attack surface, any use of it requires an
additional dependency with a large amount of difficult to audit code.
TLS is trivially DOS attacked and every major/widely used TLS
implementation has had multiple memory disclosure or remote execution
vulnerabilities even in just the last several years.

We've dodged several emergency scale vulnerabilities by not having TLS.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Christophe Biocca]

If your threat model is passive listeners, it seems to me that simply
establishing a symmetric key for each connection at handshake time
using diffie-hellman is all you need. No public private crypto needed
at all.

The whole thing seems like a bit of security theater unfortunately.
The kind of attacker that can pull off widespread passive listening is
probably able and willing to do active MITM. It's not a huge
incremental cost.

Instead, those users that do have a need for security should probably
connect to the network using Tor or I2P, which can give much better
security guarantees than anything being discussed here.

On Tue, Aug 19, 2014 at 12:58 PM, Angel Leon gubat...@gmail.com wrote:
 
 I suggest that Bitcoin Core should generate a public/private key pair and
 share the public one with peers.

 I've not read the p2p protocol of Bitcoin core, but I suppose the initial
 handshake between 2 peers would be the ideal place to exchange a public
 keys.

 would it make sense to generate a new random pair of keys per each peer you
 connect to?
 then each subsequent message to every peer gets encrypted differently,
 keeping each conversation isolated from each other encryption-speaking.

 These keys would have nothing to do with your wallet, they're just to
 encrypt any further communication between peers post-handshake. Would that
 be of any use to This could provide privacy and integrity but not
 autentication.?

 http://twitter.com/gubatron


 On Tue, Aug 19, 2014 at 12:38 PM, Gregory Maxwell gmaxw...@gmail.com
 wrote:

 On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
 justusranv...@riseup.net wrote:
  If that's not acceptable, even using TLS with self-signed certificates
  would be an improvement.

 TLS is a huge complex attack surface, any use of it requires an
 additional dependency with a large amount of difficult to audit code.
 TLS is trivially DOS attacked and every major/widely used TLS
 implementation has had multiple memory disclosure or remote execution
 vulnerabilities even in just the last several years.

 We've dodged several emergency scale vulnerabilities by not having TLS.


 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Johnathan Corgan]

On 08/19/2014 09:38 AM, Gregory Maxwell wrote:

 We've dodged several emergency scale vulnerabilities by not having TLS.

I'm still trying to understand the original premise that we want
encrypted communications between nodes.

I can certainly see the value of having *authenticated* traffic with
specific nodes, using an HMAC for the protocol messages in place of the
current checksum.

-- 
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Development Services
http://corganlabs.com
attachment: johnathan.vcf

signature.asc
Description: OpenPGP digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP43 Purpose code for voting pool HD wallets

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

We'd like to reserve two purpose codes for the HD multisig structure
that will be used for the Bitcoin wallets used for voting pools, so
we've documented the structure in the form of two BIPs. One is used
for the wallets suitable for storing bulk bitcoin deposits, the other
is used for storing colored coin deposits.

The primary difference is that bulk deposit wallets use cold storage
and are allowed to incur significant administrative overhead, where as
colored coin wallets do not use cold storage because they must be
capable of being generated on the fly.

Two draft information BIPs are attached.

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJT84VCAAoJEMP3uyY4RQ21LZcH/RYN5dUc5TjOI6Z72I4aNqDL
cZMzIo1WTK6OHsO2GUo+3L4avf+dCb2om/hDJgoLz/Oh9BMY77vF3UTIPIzGmN9X
2Oeyjg+wJG9z2L/B1f7oo4MX9c2ppUNfp2x5zDaURvME9CLkY7hLCBWp/OxU1HHb
MhLn0ICtpw3FnHddVWFwhvBxcCzJm6t2pBlM8mmTr4t52/08gklY1LVdUW0zmf9W
eFe50Y2KQ+uhVZfAga1wmFwY1pJBUmf6fAVqeK6AGDPkLVHDvN8P+mco+Qks++VZ
mTENKXWAmskGViTjd0pb8EdoSoMsDIa1eRHbpwAbbb2PEoc9pdccgwH6CscgN1I=
=R/HX
-END PGP SIGNATURE-

  BIP: BIP-
  Title:   Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
  Authors: Justus Ranvier 
   Jimmy Song 
  Status:  Draft
  Type:Informational
  Created: 2014-08-11


==Abstract==

This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).

This BIP is a particular application of BIP43 and is based on BIP44.

==Motivation==

The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed.

==Path levels==

We define the following 7 levels in BIP32 path:


m / purpose' / (5 color definition levels) / address_index


Apostrophe in the path indicates that BIP32 hardened derivation is used.

Each level has a special meaning, described in the chapters below.

===Purpose===

Purpose is a constant set to TBD (or 0xTBD) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification.

Hardened derivation is used at this level.

===Color Definition===

Index values which can be applied to a BIP32 node are limited to 4 bytes (32 bits).

Since this is not sufficient to identify color definitions without a risk of collision, multiple levels are used.

Color definitions are first shortened to 20 bytes using the Bitcoin hash160 function.

The resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels

Public derivation is used at this level.

===Index===

Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.

Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.

Public derivation is used at this level.

==Compatible wallets==

* [[https://github.com/conformal/btcd|btcd]] is the reference Bitcoin wallet for voting pools.

==Reference==

* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
* [[bip-TBD.mediawiki|BIP44 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]]
* [[http://opentransactions.org/wiki/index.php?title=Voting_Pools|Voting Pools]]

  BIP: BIP-
  Title:   Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
  Authors: Justus Ranvier 
   Jimmy Song 
  Status:  Draft
  Type:Informational
  Created: 2014-08-11


==Abstract==

This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).

This BIP is a particular application of BIP43 and is based on BIP44.

==Motivation==

The hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed.

==Path levels==

We define the following 4 levels in BIP32 path:


m / purpose' / coin_type' / series' / address_index


Apostrophe in the path indicates that BIP32 hardened derivation is used.

Each level has a special meaning, described in the chapters below.

===Purpose===

Purpose is a constant set to TBD (or 0xTBD) following the BIP43 recommendation. It indicates that the 

Re: [Bitcoin-development] Reconsidering github

[Gregory Maxwell]

On Tue, Aug 19, 2014 at 5:02 AM, Jeff Garzik jgar...@bitpay.com wrote:
 It would be nice if the issues and git repo for Bitcoin Core were not
 on such a centralized service as github, nice and convenient as it is.

 To that end, I note that Linux does its own git repo, and now requires
 2FA: 
 http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication

 As a first step, one possibility is putting the primary repo on
 bitcoin.org somewhere, and simply mirroring that to github for each
 push.

The obvious thing to do is setup the second repository and get it
going. Git doesn't really care all that much whats primary.  If we
have a working workflow elsewhere then making a change won't be a leap
of faith.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[J Ross Nicoll]

The concern is that if you can monitor traffic in and out of a single
node, you can determine which transactions originate from it vs those
which it relays. That's not great, certainly, but how many nodes
actually require that level of security, and surely they can use Tor or
VPN services if so?

Further, unless the remote nodes are in some way trusted, you're
changing the attack from read-only to requiring the ability to perform 
a man in the middle attack - that doesn't seem much harder to me.

As Gregory states, there's been at least two recent serious if not
catastrophic OpenSSL bugs, and the consequences of Heartbleed if the
Bitcoin network had been vulnerable are the stuff of nightmares.

Very difficult to see the risk/reward payoff being worthwhile.

Ross


On 19/08/2014 18:35, Johnathan Corgan wrote:
 On 08/19/2014 09:38 AM, Gregory Maxwell wrote:

 We've dodged several emergency scale vulnerabilities by not having TLS.
 I'm still trying to understand the original premise that we want
 encrypted communications between nodes.

 I can certainly see the value of having *authenticated* traffic with
 specific nodes, using an HMAC for the protocol messages in place of the
 current checksum.



 --


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/19/2014 11:38 PM, J Ross Nicoll wrote:
 That's not great, certainly, but how many nodes actually require
 that level of security

All of them.

While the rest of the 'net is busy deprecating HTTP and all other
unencrypted transport methods, why is it(*) even a debate?

Security should be on by default. Make users who don't want it jump
through hoops to turn it off instead of the other way around.


(*) where it is the desirability of blocking passive surveillance,
not the particular algorithm to use.
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJT8+AdAAoJEMP3uyY4RQ21kv8IANDkveCGJX5b5c+waXTHcEf0
MgrGlkUZgZaP+fNNME32MEeQMywkyHohZly1KKYyqf+Qi2YkZ7rFiZj5e16EtGVK
zBQCrvOyMZVv/tWPfRxrZV+jC5dUBPryaCV3XwyK3w8u5WpDhpC1be6uBjY6qtTB
58MzdMBEEwceUwDezAIpGxsr5fKw+by4WyL23HQybSgUSHWh9S9hSp4dY1L8sDdr
atdFOvjiwY7zQe9V4mrtSv2pwmWIfOJE3RBhwSdPBtsMqO0PAnUEmxKYANQjh8qV
W147aQT97DYkWb3TucY+gVbsfKSzvNoiXwvWMpmXT1Kz8wia0vX7MoPBtO6+uOk=
=6tJk
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Jeff Garzik]

Encryption is of little value if you may deduce the same information
by observing packet sizes and timings.


On Tue, Aug 19, 2014 at 7:38 PM, J Ross Nicoll j...@jrn.me.uk wrote:
 The concern is that if you can monitor traffic in and out of a single node,
 you can determine which transactions originate from it vs those which it
 relays. That's not great, certainly, but how many nodes actually require
 that level of security, and surely they can use Tor or VPN services if so?

 Further, unless the remote nodes are in some way trusted, you're changing
 the attack from read-only to requiring the ability to perform  a man in the
 middle attack - that doesn't seem much harder to me.

 As Gregory states, there's been at least two recent serious if not
 catastrophic OpenSSL bugs, and the consequences of Heartbleed if the Bitcoin
 network had been vulnerable are the stuff of nightmares.

 Very difficult to see the risk/reward payoff being worthwhile.

 Ross


 On 19/08/2014 18:35, Johnathan Corgan wrote:

 On 08/19/2014 09:38 AM, Gregory Maxwell wrote:

 We've dodged several emergency scale vulnerabilities by not having TLS.

 I'm still trying to understand the original premise that we want
 encrypted communications between nodes.

 I can certainly see the value of having *authenticated* traffic with
 specific nodes, using an HMAC for the protocol messages in place of the
 current checksum.



 --



 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 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/

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Gregory Maxwell]

On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier
justusranv...@riseup.net wrote:
 While the rest of the 'net is busy deprecating HTTP and all other
 unencrypted transport methods, why is it(*) even a debate?

I think it's desirable (and you can go look in #bitcoin-dev logs for
me talking about it in the past)— but all of engineering is
tradeoffs... and the ones involved here don't make it a high priority
in my book, esp when people should be using Bitcoin over tor in any
case, which provides better privacy and also covers encrypt + auth.

In general I think authentication is more important than encryption,
since authentication is table stakes required for a number of
anti-partitioning-attack measures.  My past thinking on opportunistic
encryption is that once you're authenticating also encrypting would be
fairly little work, but it should be auth that drives that kind of
effort.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik jgar...@bitpay.com wrote:
Encryption is of little value if you may deduce the same information
by observing packet sizes and timings.

That is simply incorrect. The resources required to do that kind of monitoring 
are very high; even the NSA can't pull it off consistently for non-targetted 
operations due to limitations on upstream bandwidth and other resources. 
(remember that many of their taps are non-cooperative ones, obtained by 
breaking into routers at ISP's) This I've confirmed with direct conversation 
with Jacob Applebaum and other Tor devs. Every additional bit of encrypted 
information flowing over the internet increases the work they need to so to 
deanonymize you. This is not unlike how CoinJoin, while not providing 
guaranteed anonymity, makes the job of attackers significantly more difficult 
by creating large amounts of statistical noise. In addition the Bitcoin P2P 
protocol has natural anti-traffic analysis properties due to its asynchronous 
nature.

Re: MITM attacks, again, the resources required to conduct them on a large 
scale instead of passive attacks just don't exist. For instance the NSA has to 
be relatively selective in using them for fear of being detected; being able to 
detect attacks is a huge improvement over the status quo anyway.

Having said that using Tor by default in Bitcoin Core is an even easier way of 
enabling encryption and authentication, and would help protect all Tor users 
from surveillance. The easiest way to do this would be to make the 
Debian/Ubuntu packages depend on Tor, and include a install-time script to 
setup the hidden service. I've verified with the Tor devs that they would 
welcome the additional load on the Tor network that Bitcoin would add.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8+jcMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhU2WB/9XE6BFxTkbjIfVn46U
uH7HCV/FSgCeSConO7LbFR2m6hN5eZ4oKcLzIi65SqRUol2eCGWVoJDsl3vuTmwF
c4gOqdieJQ6SOdHAzcolf+b3p+VwIXXUMMsO2vI6UGZvV6gFJXnZ17GASdSo9+f8
x4VxgLSunZD0xRMiMntaqPMFu1MyplomimQadW5MDt3QTa2BrOsDMwNS10NSQIAL
8ywHSKh8UddVL8ZeinE/Bhf3T1OnDVBIUCVHhhEYnKLqCnwmyY3NXH4lzXpPvo+e
LhzF7HzB5tE22vIQNb/3RimoN5FV7p4FEvgsGwT/kjjUAxgg6/LpNY5WQG6FL8nJ
/8F3
=t4/7
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Jeff Garzik]

On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd p...@petertodd.org wrote:
 On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik jgar...@bitpay.com wrote:
Encryption is of little value if you may deduce the same information
by observing packet sizes and timings.

 That is simply incorrect. The resources required to do that kind of 
 monitoring are very high; even the NSA can't pull it off consistently for

Hardly.  For example, when a new block arrives on the network, a
single observer at a single location may obtain a binary likely|not
bitcoin protocol decision from a spike in usage correlated with
sudden, global network activity after a period of inactivity.  I'll
not detail all such metrics.

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

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19 August 2014 20:21:35 GMT-04:00, Jeff Garzik jgar...@bitpay.com wrote:
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd p...@petertodd.org wrote:
 That is simply incorrect. The resources required to do that kind of
monitoring are very high; even the NSA can't pull it off consistently
for

Hardly.  For example, when a new block arrives on the network, a
single observer at a single location may obtain a binary likely|not
bitcoin protocol decision from a spike in usage correlated with
sudden, global network activity after a period of inactivity.  I'll
not detail all such metrics.

Emphasis on likely, at best. Forcing you adversary to rely on uncertain 
statistics is a huge improvement over the status quo. Secondly your example is 
of a new block; the more general concern is determining where a given 
transaction originated. In the best of circumstances determining the origin of 
a few hundred bytes of days interspersed in dozens of kB/s of buffered data 
streams is very difficult and expensive even without padding and/or random 
delay features.

Again, I've spoken to people like Jacob Applebaum about this who have a solid 
understanding of what the NSA is actually capable of, and they've confirmed the 
above. Don't let perfect be the enemy of good.

Of course, that's not to say we shouldn't cost-benefit analysis the 
implementation; not using straight OpenSSL for this is a wise decision. Hence 
the suggestion of using the existing and tested Tor support to encrypt by 
default.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8+62MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhZe/CADI+XvuCzK6N0/UUieD
WzrGexWQsqNxX2hYQpzAiYT3Y5k4CCJ3yvett0udYKS3Piqd/ihvj9RfjWe5nO+d
snPGNwFU7jSRJ+hwPdnlHfFW99LCkKOzBX0hgC+qg11SyLKcsBwE3qaiFM47G1hy
r4f1qX3Te2Kt0bUxP65d1M0Js1M0x+qLxXs6e9Gy3scFSpDjeoamgliJ6jBeeX9U
8H0mambip5CZ+diGbaMeCCRJd19XH7Nz0QgcznYScmz/3krQhtIdEJKts7bs87vh
vZyH7M4wVCiIDmDNxAIO2slo3+eopEvbOPgqjT7L72jrQgp3zVUtbJDzpSAgcB+M
vLhB
=AuCe
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19 August 2014 20:49:01 GMT-04:00, Justus Ranvier justusranv...@riseup.net 
wrote:
On 08/20/2014 12:16 AM, Peter Todd wrote:
 The easiest way to do this would be to make the Debian/Ubuntu
 packages depend on Tor, and include a install-time script to setup
 the hidden service. I've verified with the Tor devs that they would
 welcome the additional load on the Tor network that Bitcoin would
 add.

The easiest way for the people who operates nodes would be to compile
Tor into Bitcoin Core as a library so that it just works when turned
on.

That library doesn't exist yet to my knowledge, and more importantly, would 
increase the attack surface of Bitcoin Core. (much like using OpenSSL for 
straight SSL support would)

Also, my proposal of adding Tor support to the Debian packages can be 
implemented in a relatively short install time script; no code changes required.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8/KRMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhauiB/9iEvsRYQGt9lFmrtbW
SBjDt91/v7r3NcI/19aKDNGMaKl61rpzDr1zM3kIBdY3xzFoaYt+LA6O/tZVvaVC
B9zPlZsh+0ZmbU+Ejxd816DvJVDv8aO6Nt+sLuVkkN/TsBa/WCBhvwJ7ixS65/dY
WpFV7awzW+E08RETsV826scP+30lsnY5qcADoHWfuaW7HZQArpCsA+b+Amng8Vf6
mFb5GrxKlvG06w+esLSXMCISS3eMduvfzymfxBxGlgxRAqiYZRbWY3msdRRfWl3e
lISrnqZoB3G529WVGOn4o5DrzDdSJFcb8k2A/Na2J+pIxAD4Cv9vwYM2KCffbeUB
PH6x
=Mw3I
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[William Yager]

What, exactly, do we hope to achieve from having end-to-end encryption?

Even if it worked perfectly, it wouldn't be very useful.

But it won't work perfectly, because we don't have any method of
authentication. The bitcoin network is trivially MITMable. It's designed to
work even in the face of that, but any encryption we implement will just
get blown away by anyone who cares enough to stand in the middle of two
nodes.

As far as I can see, we get a microscopic obfuscatory advantage over a very
weak passive attacker, at the cost of hugely increased software complexity
(and possibly increased CPU time).

So again; what do we hope to achieve? Why bother? Not a lot of sensitive
information is transmitted in the clear. The little information that might
be considered sensitive is better protected by anonymization (a la Tor),
not encryption.
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19 August 2014 20:59:14 GMT-04:00, William Yager will.ya...@gmail.com 
wrote:
What, exactly, do we hope to achieve from having end-to-end encryption?

Even if it worked perfectly, it wouldn't be very useful.

But it won't work perfectly, because we don't have any method of
authentication.

Don't let perfect be the enemy of good.

 The bitcoin network is trivially MITMable. It's
designed to
work even in the face of that, but any encryption we implement will
just
get blown away by anyone who cares enough to stand in the middle of two
nodes.

As far as I can see, we get a microscopic obfuscatory advantage over a
very
weak passive attacker, at the cost of hugely increased software
complexity
(and possibly increased CPU time).

You realize that by your own definition even the NSA is mostly a weak passive 
attacker They do *not* have the ability to attack more than a small, targeted, 
subset of connection for both technical and political reasons. For starters, 
MITM attacks are easily detected - Bitcoin network attacked by unknown agents! 
Has your ISP been compromised? would make for great headlines and would soon 
see the problem fixed both technically and politically.

In any case, my suggestion of enabling hidden service support by default adds 
both encryption and reasonably good authentication.

-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8/ZaMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhV5UCAC0wVMyKtCedZuUKXrw
Mg6qvbkDzGyzn7fgASTnMh8hF+p+p5MoOz3K0FGTdLph+ulptz9ITatGmmi+av+u
0Fc8xXYgxiYcIwtMVumNrHR16bjG7NoShnqMujuUZ7a+xigeHxV2/tG0VRb9Km8W
GFYNdY4mOFubFu7qfqymmxGsIgP42rPsN6c41B75wqqaGzSX7BRmlxNsYVSUO3Fi
fwNU7y7hLC9BN+WQCmVK+Rk57XpXcoydfvsz9a/SLhiQKssEdcDbUq4gLtnDHs92
JBsUqzG/wDgcQFiLuAm/A/ZvDAERwPr6jtunt3CCDt+UdLwlGAj5RTnuHgY72PNS
Ma2O
=2qdX
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[William Yager]

On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd p...@petertodd.org wrote:


 Don't let perfect be the enemy of good.


I'm not. I don't think this proposal is even good.


 You realize that by your own definition even the NSA is mostly a weak
 passive attacker They do *not* have the ability to attack more than a
 small, targeted, subset of connection for both technical and political
 reasons. For starters, MITM attacks are easily detected - Bitcoin network
 attacked by unknown agents! Has your ISP been compromised? would make for
 great headlines and would soon see the problem fixed both technically and
 politically.


Again, the NSA might get an absolutely trivial amount of data from
monitoring connections on the Bitcoin network. A bit of publicity is *not*
worth drastically increasing the software complexity of the client.


 In any case, my suggestion of enabling hidden service support by default
 adds both encryption and reasonably good authentication.


Enabling hidden service support by default would introduce an insanely huge
attack surface.

And you're conflating two different things; using Tor is valuable to
Bitcoin because it would provide some anonymity. The encryption aspect is
pretty much useless for us.
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reconsidering github

[Troy Benjegerdes]

On Tue, Aug 19, 2014 at 04:58:48PM +0200, Wladimir wrote:
 On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik jgar...@bitpay.com wrote:
  It would be nice if the issues and git repo for Bitcoin Core were not
  on such a centralized service as github, nice and convenient as it is.
 
 Despite my complaining about github, I don't like the idea of moving
 somewhere else. The current way of working - to use github for storing
 the tree, and use a custom script for signing+merging - is fine with
 me.
 
 Github has a low barrier to contribution. Almost every open source
 developer already has a github account. Switching to something
 self-hosted makes it more difficult for people to contribute.
 
 Plus if we have to take the hosting upon ourselves, we have to handle
 sysadmin work ourselves as well. That's not a good use of the limited
 manpower available.
 
 Also it will be a lot of work to migrate over all the current issues
 and pulls. I don't look forward to that. I don't see the point of
 this, sorry.
 
 Wladimir

If a project cannot be organized enough to run its own hosting/web presense/
counterintelligence/security that starts with installing an OS and patching
kernels, then it is really not wise for me to trust my financial future to
software written by such a group.

There is a great deal of 'work' that is really quite pointless, particularly
in regards to claims I see about security that are irrelevant unless you 
have the understanding that comes from operating and running your own 
servers. 

This includes running DDOS protection, so no cloudflare.

If bitcoin wants to become irrelevant, then by all means, continue to 
depend on github and all the unknown attack surface it exposes.

Those of us that do run our own servers will migrate to higher quality 
alternatives.

-- 

Troy Benjegerdes 'da hozer'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

  Never pick a fight with someone who buys ink by the barrel,
 nor try buy a hacker who makes money by the megahash


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19 August 2014 21:19:43 GMT-04:00, William Yager will.ya...@gmail.com 
wrote:
On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd p...@petertodd.org wrote:
 In any case, my suggestion of enabling hidden service support by
default
 adds both encryption and reasonably good authentication.


Enabling hidden service support by default would introduce an insanely
huge
attack surface.

Hence my suggestion of separating that surface by using the standalone Tor 
binary, which runs under a different user to the Bitcoin Core binary.

And you're conflating two different things; using Tor is valuable to
Bitcoin because it would provide some anonymity. The encryption aspect
is
pretty much useless for us.

First of all, without encryption we're leaking significant amounts of 
information to any passive attacker trying to trace the origin of Bitcoin 
transactions, a significant privacy risk.

Secondly the upcoming v0.10's fee estimation implementation is quite vulnerable 
to Sybil attacks. Authentication and encryption are needed to make it secure 
from ISP-level targeting to ensure that your view of the network is 
representative. Tor support used in parallel with native connection is ideal 
here, as neither the Tor network nor your ISP alone can Sybil attack you. It's 
notable that Bitcoinj has already implemented Tor support for these same 
reasons.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8/mSMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRZjCAC4PSpQ68qgtFMR77xf
zXZLr/iMKX6yyJwXRj+vGi+0Ng/sv9NlYjYnDeflom37WlpGo/sCOFcVWImhnS2d
kUFoUH92iXwRuEt/SN/LrHghkLWOxtVu9wa49eS/piGZFF3JWllk82MgdBZ6vjNw
B6WuInEIurK+h8rUbAi2HjFkxVN0K0SsrFt/P0tHj10ABcMealBRoJh2Jx7fLNdS
uTKddqeLyThEpLGNti3k+lhwQ2dA5RUBq6q3GUS/hWvTHRnU+viGMJSYv62LXRN5
t87BXRY/R9UBpnudf3TIlPtOuIWcv2LhlXVjvbDDQqwJkvB3Qf4ejE3RZ28S5IUr
OBQH
=Gy7X
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reconsidering github

[Gregory Maxwell]

On Tue, Aug 19, 2014 at 6:26 PM, Troy Benjegerdes ho...@hozed.org wrote:
 If a project cannot be organized enough to run its own hosting/web presense/
 counterintelligence/security that starts with installing an OS and patching
 kernels, then it is really not wise for me to trust my financial future to
 software written by such a group.

Please take the hyperbole elsewhere. Good dialog it's going to happen
with the insults and adhomenem.

Regardless of where the repositories live their integrity is protected
by digital signatures and cryptographic hashes. Running them elsewhere
can be virtuous for other reasons, but it doesn't play much into this
since the same tools must be used to guarantee their security.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP: Custodial Identities

[21 e14]

As suggested before submitting a BIP, I am sending this to the mailing list.


Bitcoin is often described as “the currency of the Internet”, “the TCP/IP
of money”, or simply “the Internet of Money”. What is needed is an optional
identity layer — a Bitcoin Assigned Custodial Identities Authority, much
like the Internet Assigned Numbers Authority, to oversee global Custodial
Identity allocation. Such an authority delegates Custodial Identity Spaces
to Regional Bitcoin Custodial Identity Registries, much like the RIRs
(Regional Internet Registries) managing the allocation of Internet number
resources.

A Bitcoin Custodial Identity (BCI) account address would consist of a
Custodial Identifier allocated by the BACIA/RBCIRs (much like a bank’s
routing number), and an account address (much like an account number).
Bitcoin Custodial Identities allow dispute resolution in the legal system
for transactions in the BCI address space. Free market would drive and
determine the demand for custodial accounts. P2PKH users not affected.


Feedback is appreciated.
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Un Ix]

Excuse the ignorance, but there is something I’m not getting in this discussion.


Given it’s a published protocol, with available source code running on an open 
P2P network, why would any messages between nodes benefit from being encrypted? 
Surely all the data being processed by the network is known to any persistent 
client node(s)? 


Seems like that solution is orthogonal to the root problem, where attackers 
could monitor the network and deduce IP addresses by e.g. mapping senders of 
transactions.

  



From: Peter Todd
Sent: ‎Wednesday‎, ‎August‎ ‎20‎, ‎2014 ‎9‎:‎28‎ ‎AM
To: William Yager, bitcoin-development@lists.sourceforge.net





-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19 August 2014 21:19:43 GMT-04:00, William Yager will.ya...@gmail.com 
wrote:
On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd p...@petertodd.org wrote:
 In any case, my suggestion of enabling hidden service support by
default
 adds both encryption and reasonably good authentication.


Enabling hidden service support by default would introduce an insanely
huge
attack surface.

Hence my suggestion of separating that surface by using the standalone Tor 
binary, which runs under a different user to the Bitcoin Core binary.

And you're conflating two different things; using Tor is valuable to
Bitcoin because it would provide some anonymity. The encryption aspect
is
pretty much useless for us.

First of all, without encryption we're leaking significant amounts of 
information to any passive attacker trying to trace the origin of Bitcoin 
transactions, a significant privacy risk.

Secondly the upcoming v0.10's fee estimation implementation is quite vulnerable 
to Sybil attacks. Authentication and encryption are needed to make it secure 
from ISP-level targeting to ensure that your view of the network is 
representative. Tor support used in parallel with native connection is ideal 
here, as neither the Tor network nor your ISP alone can Sybil attack you. It's 
notable that Bitcoinj has already implemented Tor support for these same 
reasons.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8/mSMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRZjCAC4PSpQ68qgtFMR77xf
zXZLr/iMKX6yyJwXRj+vGi+0Ng/sv9NlYjYnDeflom37WlpGo/sCOFcVWImhnS2d
kUFoUH92iXwRuEt/SN/LrHghkLWOxtVu9wa49eS/piGZFF3JWllk82MgdBZ6vjNw
B6WuInEIurK+h8rUbAi2HjFkxVN0K0SsrFt/P0tHj10ABcMealBRoJh2Jx7fLNdS
uTKddqeLyThEpLGNti3k+lhwQ2dA5RUBq6q3GUS/hWvTHRnU+viGMJSYv62LXRN5
t87BXRY/R9UBpnudf3TIlPtOuIWcv2LhlXVjvbDDQqwJkvB3Qf4ejE3RZ28S5IUr
OBQH
=Gy7X
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Cameron Garnham]

We should aim to use perfect forward secrecy between all nodes by default.

This forces the attacker to do a MITM attack that is far more expensive on
the large scale.

I don't see why this is seen as so controversial.  It is relatively cheap
to implement on our side,  and has a dramatic increase of cost for any
attackers.

Cam.
On 20/08/2014 5:49 am, Un Ix slashdevn...@hotmail.com wrote:

  Excuse the ignorance, but there is something I’m not getting in this
 discussion.

 Given it’s a published protocol, with available source code running on an
 open P2P network, why would any messages between nodes benefit from being
 encrypted? Surely all the data being processed by the network is known to
 any persistent client node(s)?

 Seems like that solution is orthogonal to the root problem, where
 attackers could monitor the network and deduce IP addresses by e.g. mapping
 senders of transactions.

 *From:* Peter Todd p...@petertodd.org
 *Sent:* ‎Wednesday‎, ‎August‎ ‎20‎, ‎2014 ‎9‎:‎28‎ ‎AM
 *To:* William Yager will.ya...@gmail.com,
 bitcoin-development@lists.sourceforge.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256



 On 19 August 2014 21:19:43 GMT-04:00, William Yager will.ya...@gmail.com
 wrote:
 On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd p...@petertodd.org wrote:
  In any case, my suggestion of enabling hidden service support by
 default
  adds both encryption and reasonably good authentication.
 
 
 Enabling hidden service support by default would introduce an insanely
 huge
 attack surface.

 Hence my suggestion of separating that surface by using the standalone Tor
 binary, which runs under a different user to the Bitcoin Core binary.

 And you're conflating two different things; using Tor is valuable to
 Bitcoin because it would provide some anonymity. The encryption aspect
 is
 pretty much useless for us.

 First of all, without encryption we're leaking significant amounts of
 information to any passive attacker trying to trace the origin of Bitcoin
 transactions, a significant privacy risk.

 Secondly the upcoming v0.10's fee estimation implementation is quite
 vulnerable to Sybil attacks. Authentication and encryption are needed to
 make it secure from ISP-level targeting to ensure that your view of the
 network is representative. Tor support used in parallel with native
 connection is ideal here, as neither the Tor network nor your ISP alone can
 Sybil attack you. It's notable that Bitcoinj has already implemented Tor
 support for these same reasons.
 -BEGIN PGP SIGNATURE-
 Version: APG v1.1.1

 iQFQBAEBCAA6BQJT8/mSMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRZjCAC4PSpQ68qgtFMR77xf
 zXZLr/iMKX6yyJwXRj+vGi+0Ng/sv9NlYjYnDeflom37WlpGo/sCOFcVWImhnS2d
 kUFoUH92iXwRuEt/SN/LrHghkLWOxtVu9wa49eS/piGZFF3JWllk82MgdBZ6vjNw
 B6WuInEIurK+h8rUbAi2HjFkxVN0K0SsrFt/P0tHj10ABcMealBRoJh2Jx7fLNdS
 uTKddqeLyThEpLGNti3k+lhwQ2dA5RUBq6q3GUS/hWvTHRnU+viGMJSYv62LXRN5
 t87BXRY/R9UBpnudf3TIlPtOuIWcv2LhlXVjvbDDQqwJkvB3Qf4ejE3RZ28S5IUr
 OBQH
 =Gy7X
 -END PGP SIGNATURE-



 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development