Mem Wallet | 27 Aug 02:57 2014
Picon

standardize on bitcoin signed ecies ?


Does anyone see a value in a standardized PGP-style message,
which would allow someone performing a bitcoin transaction to
send signed encrypted messages using only public and private
bitcoin keys ?

I'd like to propose a signed encrypted message protocol, in case
someone see's value in encoding such a thing into a BIP.

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Un Ix | 20 Aug 05:23 2014
Picon

Re: Proposal: Encrypt bitcoin messages

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 <at> lists.sourceforge.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 19 August 2014 21:19:43 GMT-04:00, William Yager <will.yager <at> gmail.com> wrote:
>On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd <pete <at> 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 <at> 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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
21 e14 | 20 Aug 04:23 2014
Picon

BIP: Custodial Identities

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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Peter Todd | 20 Aug 03:14 2014

Re: Proposal: Encrypt bitcoin messages


On 19 August 2014 20:59:14 GMT-04:00, William Yager <will.yager <at> 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.

Justus Ranvier | 19 Aug 19:11 2014
Picon

BIP43 Purpose code for voting pool HD wallets


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:justus <at> monetas.net>      | Public key ID : C3F7BB2638450DB5
                                 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc

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 subtree of this node is used according to this specification. Hardened derivation is used at this level. ===Coin type=== One master node (seed) can be used for unlimited number of independent cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same space for various cryptocoins has some disadvantages. This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues. Coin type is a constant, set for each cryptocoin. The list of registered coin type constants should be obtained from BIP44. Hardened derivation is used at this level. ===Series=== Series are used by voting pools in order to implement FIFO cold storage. By directing deposits into multiple series, the private keys for most of the deposits can be kept offline, and a limited portion can be brought online to process withdrawals. Hardened 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]] * [[http://opentransactions.org/wiki/index.php?title=Voting_Pools|Voting Pools]]
Attachment (0x38450DB5.asc): application/pgp-keys, 13 KiB
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Raúl Martínez | 19 Aug 17:11 2014
Picon

Re: Proposal: Encrypt bitcoin messages

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" <me <at> 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 <rme <at> 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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

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

------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Jeff Garzik | 19 Aug 14:02 2014

Reconsidering github

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/

------------------------------------------------------------------------------
Raúl Martínez | 19 Aug 11:49 2014
Picon

Proposal: Encrypt bitcoin messages

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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Ivan Pustogarov | 19 Aug 11:34 2014
Picon

Re: [bitcoin] Add rotation of outbound connections (#4723)

I agree with this.
Some combinatorics shows that 3 persistent connections instead of 8 results in
a low success rate of the entry-peers fingerprinting attack.

> it should not disconnect any nodes which were addnode, and it should not disconnect whitelisted peers
I agree ('Addnodes' are already excluded in the example code from the pull request)

On Mon, Aug 18, 2014 at 04:51:34PM -0700, Gregory Maxwell wrote:
> It was pointed out to me that my concern wrt partitioning is unclear. Imagine
> an attacker starts up a moderate number of sybil nodes. He also connects to
> every other available listening peer and fills up their inbound capacity.
> 
> In the current network this kind of activity would only disrupt newly joining
> peers. But nodes which were still online would remain connected to each other.
> With excessive rotation the entire network could become connected exclusively
> via the sybils.
> 
> —
> Reply to this email directly or view it on GitHub.*
> 

--

-- 
Ivan

------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Peter Todd | 19 Aug 04:30 2014

Cloud mining should be using merkle sum trees to prove they aren't doing fractional reserve mining

A number of people - most recently Gavin Andresen - have speculated that
cloud hashing operations may in fact be ponzi schemes that don't
actually own the hashing power they claim to own. The claim is that the
customers upfront purchase of hashing power is simply kept and used to
pay off existing customer profits rather than actually being used to
purchase mining equipment.

We can use merkle sum trees to detect this fraud cryptographically:

1) Put the MH/s paid for by each account into a merkle sum tree, each
with a customer supplied unique identifier. (like their email address)
This allows the customer to verify that the hashing power they paid for
has been included in the total hashing power claimed.

2) Mark blocks found by the operation publicly so they can be associated
with the specific cloud mining operation; putting the merkle sum tree
root hash into the coinbase or an OP_RETURN output would be ideal. This
allows anyone to verify that the hashing power claimed corresponds to
the # of blocks actually found.

--

-- 
'peter'[:-1] <at> petertodd.org
0000000000000000201d505432d708aa2edb656f6fe34d686b37d4747e5ff389
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Gregory Maxwell | 18 Aug 20:13 2014
Picon

Fwd: Outbound connections rotation

On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille <pieter.wuille <at> gmail.com> wrote:
> Yes, I believe peer rotation is useful, but not for privacy - just for
> improving the network's internal knowledge.
>
> I haven't looked at the implementation yet, but how I imagined it would be
> every X minutes you attempt a new outgoing connection, even if you're
> already at the outbound limit. Then, if a connection attempt succeeds,
> another connection (according to some scoring system) is replaced by it.
> Given such a mechanism, plus reasonable assurances that better connections
> survive for a longer time, I have no problem with rotating every few
> minutes.

Previously when you and I had discussed this I'd proposed that some
number (say) four of the most long lived connections which had proven
themselves useful (e.g. by relaying blocks) be pinned up and not be
eligible for dropping. By protecting some subset of peers you
guarantee that an attacker which simply introduces a lot of nodes
cannot partition the network which existed prior to when the attack
started.

On Mon, Aug 18, 2014 at 10:27 AM, Mike Hearn <mike <at> plan99.net> wrote:
> I think the attack Ivan is talking about does not require sybil attacks to work though, just listening to
lots of peers

I may not be understanding you. Might be a definitions thing, I'm
using the definition: A sybil attack is when a party takes on many
identities (nodes) in the network.

What ivan highlights is a bit of a tradeoff between concealing
identities and linkages.  Relaying transactions through only a single
peer ever (until that one is no longer on the network) is the best
strategy for concealing your identity (ignoring tor and what not), as
only that peer learns anything about your identity.  But it may reveal
a lot about how different transactions are linked, since people
observing that peer will observe that your transactions are
correlated.

The optimal strategy for avoiding linkages (ignoring tor, again), is
to randomly pick a different peer for each transaction and relay the
transaction only to that peer.  This can (and probably should) be
distinct from your normal network connectivity.

Probably for anti-linkage I'd suggest that a facility for that kind of
announcement should be done. If used over tor it would also protect
your identity.   Then the regular topology of the network can be
optimized for learning and partition resistance.

------------------------------------------------------------------------------

Gmane