Wladimir | 1 Sep 10:25 2014
Picon

Testing and reviewing requested for work on Bitcoin Core wallet

Hello,

Cozz Lovan has been doing great work on Bitcoin Core's wallet code lately.

If anyone cares about Bitcoin Core's wallet, for example its
performance, do help testing and reviewing these improvements so that
they can make it into 0.10:

Subtract fee from amount
https://github.com/bitcoin/bitcoin/pull/4331

[Wallet] Improve ReorderTransactions(..)
https://github.com/bitcoin/bitcoin/pull/4697

[Wallet] Replace OrderedTxItems(..) with in-memory map
https://github.com/bitcoin/bitcoin/pull/4702

[Qt] Call checkBalanceChanged() periodically instead for every updated tx
https://github.com/bitcoin/bitcoin/pull/4712

Move g_signals.SetBestChain(..) below SyncWithWallets
https://github.com/bitcoin/bitcoin/pull/4798

[Wallet] Call SetBestChain before and after rescan
https://github.com/bitcoin/bitcoin/pull/4800

[Wallet] Do not flush the wallet in AddToWalletIfInvolvingMe(..)
https://github.com/bitcoin/bitcoin/pull/4805

Wladimir
(Continue reading)

Matt Corallo | 28 Aug 22:21 2014

RIP Hal Finney

I'm sure many of you have already seen this, but Hal Finney passed away
on Tuesday. While his body is being cryogenically preserved, we should
all take a moment to thank Hal for everything he did for the cypherpunk
community, specifically helping hugely in the early days of Bitcoin as
well as PGP.

Matt

http://lists.extropy.org/pipermail/extropy-chat/2014-August/082585.html

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Wladimir | 28 Aug 16:41 2014
Picon

[ann] Bitcoin Core 0.9.3 rc1 is available for download

Bitcoin Core version 0.9.3rc1 is now available from:

  https://bitcoin.org/bin/0.9.3/test/

This is a release candidate (test version) for a new minor version
release, bringing
only bug fixes and updated translations.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading
==========================

How to Upgrade
--------------

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.3 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.

Downgrading warnings
--------------------

(Continue reading)

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

Gmane