Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-17 Thread devrandom


On 2015-03-12 03:28 AM, Andreas Schildbach wrote:
 That doesn't work for mobile wallets, because we need to consider the
 offline case. To fix this, we'd need to extend BIP70 to tell the
 merchant where to forward the half-signed transaction to. Then again I'm
 not sure if we want that, for privacy reasons. In any case, practical

Telling the merchant who my security provider is not that different from
a privacy point of view from using their wifi.  In both cases they would
see us connect to the provider.  The connection / payload would be
encrypted of course.

In the mean time, we can un-multisig some of the coins for daily use, up
to a defined velocity limit.  (credit to Mike Hearn's for this idea)

 multisig is still a looong way off.

Let's bring it closer.  p2sh.info shows an exponential increase,
currently at 8%.  At this rate, the majority of the coins will be
multisig near the end of the year.

 
 
 
 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

-- 
devrandom / Miron

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread devrandom
ACK.  CryptoCorp uses this method for our external signer service.

On 2015-03-11 04:45 AM, Thomas Kerin wrote:
 
 Hi all,
 
 I just created a PR on bitcoin/bips for a proposed standard for creating
 standard multisignature P2SH addresses given m, and a set of public keys.
 
 https://github.com/bitcoin/bips/pull/146
 
 I used BIP0090 as a place-holder, but I would like to request a BIP
 number for this now.
 
 All the best,
 
 
 
 
 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 
 
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

-- 
devrandom / Miron

-- 
devrandom / Miron

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-11 Thread devrandom
On 2015-03-11 05:11 PM, Gregory Maxwell wrote:
 On Wed, Mar 11, 2015 at 11:50 PM, devrandom c1.sf-bitc...@niftybox.net 
 wrote:
 That said, I do agree that mnemonic phrases should be portable, and find
 it unfortunate that the ecosystem is failing to standardize on phrase
 handling.
 
 The fact remains that there are several apparently unresolvable
 well-principled perspectives on this subject.
 
 (And I can speak to this personally: There are several BIPs in this
 space that I'd rather not see in product with my name on it.)
 
 Unless two wallets have exactly the same feature set, cross importing
 keys is going to confuse or break something. Even if you're trying to
 be fairly generic the testing overhead for all possible strategies and
 structures is large. Expecting compatibility here would be like
 expecting two large commercial accounting packages to support the same
 internal file formats. Compatibility is only straight forward when the
 feature set is as limited as possible.

You make some good points.  However, I still hope for standardization by
profile.  E.g. a consumer profile for wallets with just one account,
a business profile for small business wallets.  If an application
falls outside of the standardized profiles, they can roll their own or
try to promote a new standard.

I think there are some important advantages to not being forced to use
the old wallet to send coins when switching wallets. The three I can
think of right now are: maintaining transaction history, emergency
transition when a wallet has a serious (e.g. money losing) bug and web
wallet with server down.

Another important reason to standardize is to reduce the roll your own
crypto temptation on the wallet creator part, where the wallet-specific
algorithm is more likely to contain weaknesses.

I do agree that trying to come up with one uber standard will likely
fail and is probably counter productive.

 
 The space for weird behavior to harm users is pretty large... e.g. you
 could load a key into two wallets, such that one can see all the funds
 by the other, but not vice versa and and up losing funds by
 incorrectly assuming you had no coins; or inadvertently rip of your
 business partners by accounting for things incorrectly.
 
 Even ignoring compatibility, most demanded use cases here are ones
 that create concurrent read/write use of single wallet without some
 coordinating service is inherently somewhat broken because you can
 double spend yourself, and end up with stalled and stuck transactions
 and causing people to think you tried ripping them off.
 
 I certainly recognize the desirable aspects of just being able to load
 a common wallet, and that inexperienced users expect it to just work.
 But I don't think that expectation is currently very realistic except
 within limited domains. It may be more realistic in the future when
 the role of wallets is better established. I don't see any _harm_ in
 trying to standardize what can be, I just don't expect to see a lot of
 success.
 
 Ultimately, the most fundamental compatibility is guaranteed:  you can
 always send your funds to another wallet. This always works and
 guarantees that you are never locked in to a single wallet. It is well
 tested and cannot drive any software in to weird or confused states.
 

-- 
devrandom / Miron

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to address Bitcoin malware

2015-02-02 Thread devrandom
 

-- 
devrandom / Miron

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions

2015-01-14 Thread devrandom
At CryptoCorp we recommend to our customers that they sort
lexicographically by the public key bytes of the leaf public keys.  i.e.
the same as BitPay.

On Wed, 2015-01-14 at 17:37 +0100, Ruben de Vries wrote:
 For p2sh multisig TXs the order of the public keys affect the hash and
 there doesn't seem to be an agreed upon way of sorting the public
 keys.
 
 
 If there would be a standard (recommended) way of sorting the public
 keys that would make it easier for services that implement some form
 of multisig to be compatible with each other without much hassle and
 making it possible to import keys from one service to another.
 
 
 I'm not suggesting forcing the order, just setting a standard to
 recommend, there doesn't seem to be much reason for (new) services to
 not follow that recommendation.
 
 
 Ryan from BitPay broad this up before
 (https://sourceforge.net/p/bitcoin/mailman/message/32092958/) and in
 bitcore they've implemented lexicographical sorting on the hex of the
 public key.
 In a short search I can't find any other library that has a sorting
 function, let alone using it by default, so bitcore is currently my
 only reference.
 
 
 
 
 ​Ruben de Vries
 ​CTO, BlockTrail
 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___ Bitcoin-development mailing 
 list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
Miron / devrandom




--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Detailed gitian build guide

2014-04-03 Thread devrandom
On Thu, 2014-04-03 at 07:51 +0200, Wladimir wrote:
 
 On Thu, Apr 3, 2014 at 6:47 AM, devrandom c1.sf-bitc...@niftybox.net
 wrote:
 Nice!
 
 I wonder how much of this could be scripted.
 
 
 Everything, probably, using vmbuilder (and/or vagrant as Nick Simpson
 suggests). But that's not the point here. It is to provide exact steps
 that people can follow to get a basic (virtual) machine that they can
 use to do gitian builds.

Understood.
 
 I didn't want to end up with a
 gitian-builder-that-builds-a-gitian-builder :-) The host machine may
 not even have any scripting languages installed (in the case of
 Windows).

Yes, I can see the turtles there.
 
 
 It may be possible to script *some* parts (most of the quoted bash
 script is runnable as script) without automating the entire process,
 but I hope that over time we can make Gitian itself easier to
 use/setup, so that less steps are needed in the first place.

Understood. :)  I would definitely like to see in Gitian any
improvements that make it easier for newcomers to get started.
 
 
 Wladimir
 
 
 

-- 
Miron / devrandom




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


Re: [Bitcoin-development] Detailed gitian build guide

2014-04-02 Thread devrandom
Nice!

I wonder how much of this could be scripted.

On Wed, 2014-04-02 at 14:27 +0200, Wladimir wrote:
 Hello all,
 
 
 I'm working on a detailed guide on how to install and set up a Debian
 VM for gitian building. As this guide can be used on any operating
 system that has VirtualBox, hopefully this will make it easier for
 people to get started with gitian builds.
 
 
 See https://github.com/bitcoin/bitcoin/pull/3994
 
 
 Rendered version is here:
 https://github.com/laanwj/bitcoin/blob/2014_04_debian_gitian_build_doc/doc/gitian-building.md
 
 
 
 Comments and patches are welcome.
 
 If you bump into problems while following the guide please let me
 know.
 
 
 
 Wladimir
 
 
 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
Miron / devrandom




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


Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-03-29 Thread devrandom

On Sat, 2014-03-29 at 11:44 -0400, Matt Whitlock wrote:
 On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
  https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
 
 Thanks. This is great, although it makes some critical references to an
 ACM paper for which no URL is provided, and thus I cannot implement it.
 
 A distributed ECDSA notwithstanding, we still need a way to decompose a
 BIP32 master seed into shares. I am envisioning a scenario in which I

It would seem that threshold ECDSA with keys derived from separate seeds
has better security properties than one seed that is then split up.  The
main thing is that there is no single point of attack in the generation
or signing.

 might meet my sudden and untimely demise, and I wish to allow my
 beneficiaries to reconstruct my wallet's master seed after my death. I
 would like to distribute seed shares to each of my beneficiaries and
 some close friends, such that some subset of the shares must be joined
 together to reconstitute my master seed. Shamir's Secret Sharing Scheme
 is perfect for this use case. I am presently working on extending my
 draft BIP so that it also applies to BIP32 master seeds of various
 sizes.
 
 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
--
Miron / devrandom



-- 
--
Miron / devrandom




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


Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-03-29 Thread devrandom
On Sat, 2014-03-29 at 13:38 -0400, Matt Whitlock wrote:
 On Saturday, 29 March 2014, at 10:25 am, Dev Random wrote:
  On Sat, 2014-03-29 at 11:44 -0400, Matt Whitlock wrote:
   On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
   
   Thanks. This is great, although it makes some critical references to an
   ACM paper for which no URL is provided, and thus I cannot implement it.
   
   A distributed ECDSA notwithstanding, we still need a way to decompose a
   BIP32 master seed into shares. I am envisioning a scenario in which I
  
  It would seem that threshold ECDSA with keys derived from separate seeds
  has better security properties than one seed that is then split up.  The
  main thing is that there is no single point of attack in the generation
  or signing.
 
 No contest here. But can threshold ECDSA work with BIP32? In other
 words, can a threshold ECDSA public key be generated from separate,
 precomputed private keys, or can it only be generated interactively?
 Maybe the BIP32 master seeds have to be generated interactively, and
 then all sets of corresponding derived keys are valid signing groups?

That's a good point. In the paper, they have a deterministic wallet
scheme in section 3.3.  It is non-interactive, so that's good.  On the
other hand, it's not BIP32, so that adds complexity.

 
 Threshold ECDSA certainly sounds nice, but is anyone working on a BIP
 for it? I would take it on myself, but I don't understand it well
 enough yet, and publicly available information on it seems lacking. I
 proposed this Shamir Secret Sharing BIP as an easily understood, easily
 implemented measure that we can use today, with no changes to existing
 Bitcoin software. It's low-hanging fruit.

Good points, although multisig is catching on quickly in the ecosystem.
AFAIK, all production wallets can send to p2sh addresses.

-- 
Miron / devrandom




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