Re: [Bitcoin-development] Electrum 2.0 has been tagged
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
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
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] convention/standard for sorting public keys for p2sh multisig transactions
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
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
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
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
