Re: [Bitcoin-development] bip44 GPG identities - POC demo
On 07/03/15 16:53, Mem Wallet wrote: this allows a user to manage a GPG identity for encryption and signing with zero bytes of permanent storage. (on tails for example) Hi! As an author of BIP44 I don't think that you should use BIP44 for this and a new BIP number should be allocated. To me it does not make much sense to create GPG key hierarchy per Bitcoin account, but rather create a GPG key hierarchy per device/master seed. I am currently in process of implementing a SignIdentity message for TREZOR, which will be used for HTTPS/SSH/etc. logins. See PoC here: https://github.com/trezor/trezor-emu/commit/9f612c286cc7b8268ebaec4a36757e1c19548717 The idea is to derive the BIP32 path from HTTPS/SSH URI (by hashing it and use m/46'/a'/b'/c'/d' where a,b,c,d are first 4*32 bits of the hash) and use that to derive the private key. This scheme might work for GPG keys (just use gpg://u...@host.com for the URI) as well. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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] Request for a new BIP number (and discussion): Improved HD wallet generation.
On 21/02/15 14:49, 木ノ下じょな wrote: Thank you for your feedback. I have written the Abstract and Motivation. Much better. Thanks! -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for a new BIP number (and discussion): Improved HD wallet generation.
On 21/02/15 14:20, 木ノ下じょな wrote: I have put together a proposal for a new generation methodology of HD wallets. Your proposal is missing Abstract and Motivation sections. Abstract tells us WHAT are trying to achieve, Motivation tells WHY. It's not worth to dig into technical details of your implementation until these two questions are answered. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Export format for xpub
On 03/02/15 11:37, Andreas Schildbach wrote: Not really IMHO. Keys can be used on multiple blockchains. Ah, correct. Timestamp it is. Nitpick: They cannot be used on multiple blockchains according to BIP32. In BIP43 we fixed that. :-) -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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] Export format for xpub
On 03/02/15 10:33, Levin Keller wrote: bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]path=[path in derivation tree]subchains=[numbers]creationdate=[unixtimestamp] I cannot come up with an usecase where path parameter would be needed. FWIW childnumber and depth are already expressed in xpub itself. I like the general idea of subchains parameter, but I would like to further specify it: a) parameter should contain values described as comma separated list of values (such as 0,1,2,3,4) b) consecutive values can be shortened via dash (0,1,2,3 == 0-3) c) should we allow non-consecutive values (e.g. 0,1,3,8)? I am not sure. If not the subchains param can contain just upper bound of indexes to scan (e.g. 3) d) a wallet uses just the first specified chain to generate receiving addresses, uses the other chains just to add to the balance OR should a wallet be able to generate receiving address for second, third, etc. external chain? if yes, we should split subchains param into external and internal params both containing a list of numbers. this seems like an overkill to me and I am fine with using just the first chain as the external one. Why not have more descriptive parameters? Saving on data? Yes. The longer the string, the bigger the QR code. I am a big fan of unix timestamps. Would vote for Andreas' format on the creation date. I am not against Unix timestamps, I just said I expected something else there. Unix timestamps have a lot of advantages. Another option that might make sense is the block number. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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] Export format for xpub
On 03/02/15 01:05, Andreas Schildbach wrote: I don't think that parameterizing will work, we can't predict future BIPs. It's the same as for BIP43, in the end we agreed on just putting the BIP number. Hm, let me put the questions the other way around: What gap limit should a wallet use if it encounters h=bip32? What h value should I use for myTREZOR wallets? Which is essentially a BIP44 wallet that produces h=bip32 xpubs with gap limit 20 ... -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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] Export format for xpub
On 02/02/15 12:33, Mike Hearn wrote: We generally don't edit BIPs like that after they've been written except to I think this could end up in BIP43, which deals with hierarchies and is still in Draft state although widely used. Allocating new BIP seems like a overkill to me. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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] Export format for xpub
On 02/02/15 15:17, Andreas Schildbach wrote: Yes, except that BIP32-hierarchy and BIP44 differ in some requirements (e.g. gap limit). Right. To me it seems more important to describe how addresses should be discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G) instead of how the xpub was created/obtained (bip32 vs bip44). What do you thing about changing ?h=bip32 to something like ?t=01g=20 - t=01 meaning that chains 0 and 1 should be scanned (feel free to change 01 into any other descriptive string) - g=20 meaning that gap 20 should be used Those strings are not meant to be read by humans. MMDD is more complicated than necessary, given that Bitcoin deals with seconds since epoch everywhere. OK :-) -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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
On 14/01/15 20:27, Jeffrey Paul wrote: To clarify: the raw bytes of the public key itself, not the ascii base58 representation of the pubkey hash - right? Could you give an example of two pubkeys where the following condition is met? raw(pubkey1) raw(pubkey2) and base58(pubkey1) base58(pubkey2) -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- 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] cryptographic review requested
On 10/22/2014 10:46 AM, Chris D'Costa wrote: Looks great, but how would you resolve the problem of knowing for certain that the public key you have received to encrypt the message is not from a MITM? Isn't this the same problem with PGP? -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] cryptographic review requested
On 09/23/2014 11:12 PM, Mem Wallet wrote: - M,Sender_Address = ReceiveMessage( eM, Decrypting_Key ) It is acceptable for deterministic nonces to be used for signatures, however nonces generated for ECIES must be high quality random bytes. (excepting unit test vectors) Could you please describe what might get wrong if one uses deterministic nonces for ECIES as well? Thanks! -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] cryptographic review requested
On 09/23/2014 11:12 PM, Mem Wallet wrote: communication. To address gmaxwell's criticism, I'd like to also follow up with a proposed change to BIP44, such that a structured wallet would also include a series of identity keys, both addresses which will be used for signing, and public keys which would be used as destinations for encrypted messages. I don't know what criticism it was, but I feel that another BIP than BIP44 should be created to describe which HD paths should be used for ECIES. If anyone is familiar with ECIES and would be interested, there is a working implementation at http://memwallet.info/btcmssgs.html, which also includes this whitepaper: That looks great! I already implemented Electrum's way of ECIES into TREZOR firmware, but yours version seems much more complete, so I am inclined to throw it away and use your implementation. Have you thought about pushing this as a new BIP (different one than I mention above)? I think it's important to have it reviewed and standardized ASAP. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.12
On 10/03/2014 02:49 PM, Mike Hearn wrote: I’m pleased to announce version 0.12 of bitcoinj This release represents 8 months of work. The biggest new feature is HD wallets. Congratulations on this release and I am quite happy that bitcoinj now fully supports BIP32 and BIP39! Does it also support various HD wallet structures such as BIP44 for example? -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcing the Statoshi fork
On 05/07/2014 09:12 PM, Jameson Lopp wrote: I've created a Bitcoin Core fork that outputs statistics to StatsD. How complex is the patchset? Would it be possible to merge it into the mainline and enable compilation of this feature conditionally by some build-time option? -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk signature.asc Description: OpenPGP digital signature -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?
On 04/26/2014 12:48 PM, Tier Nolan wrote: Maybe the solution is to have a defined way to import an unknown wallet? That is nonsense. There is no way how to import the wallet if you don't know its structure. Given a blockchain and a root seed, it should be possible to find all the addresses for that root seed. Unless the keyspace is almost infinite because: The hierarchy that the wallet actually uses could be anything. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 08:39 PM, Tier Nolan wrote: A merchant could easily send 20 addresses in a row to customers and none of them bother to actually buy anything. Such merchant would surely use some merchant system instead of generic wallet software. Setting the gap limit to high is just a small extra cost in that case. Not if you have 100 accounts on 10 different devices. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 09:00 PM, Tier Nolan wrote: The point is to have a single system that is compatible over a large number of systems. There is such system and it is called BIP32. On the other hand, in BIP64 we try to put a set of restrictions and rules on top of BIP32. There will always be some special usecases where BIP64 is not a good fit and there's no reason why you cannot use BIP32 in a different manner using a different purpose field. Examples: Electrum does not want to use accounts and they start to use scheme m/65'/change/address (where change = 0 or 1). Or Andreas Schildbach wants to have refunds chain so he uses m/66'/chain/address (where chain = 0, 1 or 2). We wanted to find one good solution that fits all, but unfortunately it turned out everyone wants something a little bit different. The point of the whole effort is that you can have ONE SINGLE BACKUP (master node) for all these independent purposes and suddenly claims such as my wallet is BIP64 and BIP66 compatible actually mean something as opposed to BIP32 compatible which actually means nothing except that the wallet author is capable of using HMAC in context of generating the tree. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 09:44 PM, Luke-Jr wrote: Why do clients need to use the features in BIP 64? If Electrum doesn't want to use accounts, then it can just use account 0 for everything. Refund chains are As Andreas wrote earlier in this thread: There is no bare minimum. Either you implement the BIP fully or not. What you suggest does not follow the principle of least surprise. Suppose user imports his BIP64 compatible wallet into Electrum, which claims it is BIP64 compatible, but actually implements just a subset of the spec (sticking account index to 0). The user now sees just a fraction of his coins and is puzzled. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 10:01 PM, Luke-Jr wrote: Yes, it should scan all possible (under the BIP-defined structure) branches regardless of which features it supports. So you suggest to scan for accounts, show balances but don't allow user to spend them? Does not seem right to me. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 10:09 PM, Luke-Jr wrote: Scan all branches for UTXOs, then you have the balance for the wallet. Account balances are metadata, so cannot be known from the seed alone. If you want to have a way to restore accounts, you must define some more detailed wallet file format (which could be built on top of this). I think one of the following is happening: a) you have not read the document b) you don't understand what accounts are, because you have not read the document c) you don't understand how restoring accounts work, because you have not read the document d) you don't understand that accounts funds are not meant to be mixed together, because you have not read the document e) I got your emails wrong because I am not a native speaker, but please read the the document ;-) -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 10:32 PM, Luke-Jr wrote: f) I missed the part where BIP 32 redefined account to mean subwallet instead of what has traditionally been called account in Bitcoin. Ah, okay. The last time I saw Bitcoin-qt it was still using independent addresses. In that case, single-subwallet wallet software probably needs to have the user provide a subwallet number in addition to the seed. Which brings us back to my original complaint that the user can be confused because he doesn't see all his funds. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 10:41 PM, Luke-Jr wrote: I don't see how. The user knows he has money in different subwallets. As long as he has a way to specify which subwallet he is accessing in single-subwallet clients, there shouldn't be a problem. Right. But these clients have no right to call themselves BIP64 compatible then. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 11:18 PM, Luke-Jr wrote: Only a very niche user base needs funds isolated... Our users do and we are creating this BIP for them, because we love them. ;) -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 11:22 PM, Gregory Maxwell wrote: Hopefully it would be clarified as only a MUST NOT do so silently... I have funds split across two wallets and it WONT LET ME SPEND THEM sounds like a terrible user experience. :) That is a subjective matter. To me it makes PERFECT SENSE that funds across accounts NEVER MIX. One can still send funds from one account to another and then perform another spend. That's what I consider a consistent and thus GOOD user experience. What's the purpose of Accounts if wallet mixes coins among them anyway? I know it's not good to use classic bank accounts as analogy, but that's exactly how they work. Or have you every done ONE transaction from two bank accounts simultaneously? -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 04/23/2014 11:42 PM, Pieter Wuille wrote: In that case, maybe it makes sense to define another purpose id without accounts as well already. I believe many simple wallets will find multiple subwallets too burdening for the user experience, or not worth the technical complexity. Right. See my previous email where I describe hypothetical creation of BIP65 and BIP66 which the exact thing you describe. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 03/27/2014 08:09 AM, Tamas Blummer wrote: A notable suggestion was to instead of building a directory of magic numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word Bitcoin, Litecoin, Dogecoin, so collosion is unlikely and cetral directory is not needed. Nice idea, but keep in mind that you are hashing into 2^32 space, so collisions will occur, unfortunately and we'll end up with directory again :-/ Even if they did not occur you would need to keep up the registry of names anyway (is it Peercoin or PPCoin, Testnet or TestNet ...)? -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 03/26/2014 09:49 PM, Mike Hearn wrote: - cointype: This is zero for Bitcoin. This is here to support two things, one is supporting alt coins based off the same root seed. Right now nobody seemed very bothered about alt coins but sometimes feature requests There is one altcoin that is pretty important even today and it is Testnet. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 03/27/2014 01:06 PM, Thomas Voegtlin wrote: Yes, I was planning to increase the number of available unused addresses to 10 or 20 in the bip32 version of Electrum. Also, we'd need to specify a gap limit for accounts as well. In TREZOR we currently use 0, which means that the scan will stop as soon as we hit first account with no transaction history (meaning that its first X=10 addresses are unused). -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 03/27/2014 02:53 PM, Thomas Voegtlin wrote: Note: Maybe we could just look at the first address of each account, instead of the first 10 ? This is a possible optimization, but it adds unnecessary logic. Also it does not decrease the number of required requests between a client and a server (e.g. when backend sends responses in bulks of 10 addresses or more). -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 03/27/2014 04:57 PM, Allen Piscitello wrote: Don't most of these coins have a magic number already assigned that is unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for Litecoin, etc...). This seems like a good candidate for identifying coins, and also supports Testnet cases well. Maybe there are some alts without such a magic number that might prevent that? That magic number is something I find very unfortunate and superflous in BIP-32 design. Its only purpose is to distinguish BIP-32 trees for various altcoins, but it doesn't make sense at all once you start storing various altcoins in the same tree using the proposed /m/cointype/reserved'/account'/change/n scheme. I would love to see that removed from BIP-32 and use always 0x0488B21E/0x0488ADE4 (xpub/xpriv), but that is for different discussion I guess. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On 03/27/2014 05:14 PM, Pieter Wuille wrote: That said, I'm not convinced about the extra layers. The cointype in my opinion isn't necessary inside the derivation. There is already support (4 bytes!) for magic bytes in the serialized form. Inside Cointype in path is for separation purposes, not for identification. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote: So upon entering a password with a typo, the user will not be notified of an error, but be presented with a wallet balance of 0, after the blockchain has been scanned. I'm sorry, but that's not the kind of experience I would want to present to my users. Sure, you can have either plausible deniability or typo checking, not both at the same time. Would you care to elaborate how optional outsourcing of the KDF breaks compatibility? I'm afraid one would end up with code generated in one client that is unusable in a different client, because the client's developer thought that using fancier algorithm instead of the proposed ones was a good idea. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On 03/12/2014 08:55 PM, William Yager wrote: The proposed BIP uses a bloom filter, so it has both plausible deniability *and *typo checking. The bloom filter is optimized for two elements and will catch something like 99.9975% of typos, despite allowing two different passwords. Ok, I see. So the spec allows one real and one fake password. That is something I don't consider plausible deniability. I am not saying that this solution is wrong, I find it quite interesting, but it's not plausible deniability. ;-) I'm afraid one would end up with code generated in one client that is unusable in a different client, because the client's developer thought that using fancier algorithm instead of the proposed ones was a good idea. This is clearly in violation of the spec. Ah, I misunderstood. I thought that outsourcing the KDF means allowing the 3rd party to use any KDF instead of the specified ones. What would be the reason to outsource if this is not possible, anyway? -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On 03/12/2014 09:10 PM, William Yager wrote: implement this is to allow semi-trusted devices (like desktop PCs) to do all the heavy lifting. The way the spec is defined, it is easy to have a more powerful device do all the tough key stretching work without significantly compromising the security of the wallet. By disclosing preH to compromised computer (between steps 4 and 5) you make further steps 5-9 quite less important. Too bad you started to work on spec just recently. :-/ -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
On 03/12/2014 09:37 PM, William Yager wrote: (that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to implement even on devices that only have a few kB of RAM, and even though our number of rounds is very aggressive (2^16 and 2^21), it will still run in reasonable time even on very slow embedded ARM processors. To give you some numbers: TREZOR (120MHz ARM) does 1024 rounds of PBKDF2-HMAC-SHA512 in around 1 second. So 2^16 is around one minute, 2^21 is around half an hour. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
On 02/24/2014 05:45 PM, Gavin Andresen wrote: 40 bytes is small enough to never require an OP_PUSHDATA1, too So are 75 bytes. (I'm not trying to push anything. Just saying ...) -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
On 02/10/2014 12:33 AM, Pieter Wuille wrote: The proposed document is here: https://gist.github.com/sipa/8907691 If we are bumping nVersion, how about dropping DER encoding completely and using just 64 bytes directly for signature? Also using 2 different variable integer encodings (in addition to what DER already does) is very confusing. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to replace BIP0039
On 04/11/13 16:10, Timo Hanke wrote: Does Trezor even use private derivation? No. It can't. Private keys never leave the device so client would not know how to generate addresses. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to replace BIP0039
On 03/11/13 08:40, Timo Hanke wrote: Trezor picks random s and sends S=s*G to computer, keeping s secret. That's a really neat trick! One question remains: if you only write down the mnemonic how can you be sure that it is correct and corresponds to the secret in Trezor? Right. That's a problem. I'm not sure if this whole cryptomagic is benefitial at all. I'd suggest to go the easy way for now, i.e. prove that external entropy was used while generating the master seed. If the user does not trust our firmware, he can use his own built one. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP39 word list
On 19/10/13 01:58, Gregory Maxwell wrote: https://people.xiph.org/~greg/wordlist.visual.py I've included the search utility I used below. Yeah, there are lots of tools on the Internet. Posting links to them is not helping. Sending pull requests with particular changesets with explanation is. Well, or rather was. I think we are past the point where it was wise to introduce changes to the word list ... (especially when 50 people have 51 different opinions on this topic) -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys
On 10/09/13 23:03, Matthew Mitchell wrote: Maybe it would have been better without the aggressive words? Feel free to come up with wordlist enhancements. That's why we put this BIP for discussion in the first place. Three people went through the wordlist numerous number of times and as you can see it's still not perfect. Please bear in mind that for every word you remove from the list, you have to come up with a good alternative that is unique and hard to confuse with the others. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
