Re: [Bitcoin-development] bip44 GPG identities - POC demo

2015-03-07 Thread Pavol Rusnak
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.

2015-02-21 Thread Pavol Rusnak
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.

2015-02-21 Thread Pavol Rusnak
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

2015-02-03 Thread Pavol Rusnak
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

2015-02-03 Thread Pavol Rusnak
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

2015-02-02 Thread Pavol Rusnak
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

2015-02-02 Thread Pavol Rusnak
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

2015-02-02 Thread Pavol Rusnak
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

2015-01-14 Thread Pavol Rusnak
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

2014-10-22 Thread Pavol Rusnak
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

2014-10-22 Thread Pavol Rusnak
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

2014-10-21 Thread Pavol Rusnak
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

2014-10-03 Thread Pavol Rusnak
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


[Bitcoin-development] BIP32 - invalidation

2014-08-08 Thread Pavol Rusnak
Hi all!

I would like to discuss invalidation of nodes in BIP32. Currently the
document says:

a) Public CKD

In case I_L = n or ki = 0, the resulting key is invalid, and one should
proceed with the next value for i.

b) Private CKD

In case I_L = n or Ki is the point at infinity, the resulting key is
invalid, and one should proceed with the next value for i.

c) Master Key Generation

In case IL is 0 or I_L = n, the master key is invalid.

(All these cases have probability lower than 1 in 2^127.)

What do you think about the following change for all 3 cases:

In case I_L = n assign I_L := I_L mod n.

Rationale:

It's easy to say mark as invalid and proceed with next, but actually
most of the implementations don't do the checking at all, because tjen
it's rather hard at application level to implement skipping logic. OTOH
it's quite straightforward to perform modulo if needed, so we probably
see more implementations doing the checking.

We would still need to deal with cases when I_L = 0 or ki = 0 or ki =
inf, but these have probability around 1 in 2^255.

Does anyone see any concerns when it comes to security of the proposed
change?

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Announcing the Statoshi fork

2014-05-07 Thread Pavol Rusnak
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?

2014-04-26 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-04-23 Thread Pavol Rusnak
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

2014-03-27 Thread Pavol Rusnak
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

2014-03-27 Thread Pavol Rusnak
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

2014-03-27 Thread Pavol Rusnak
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

2014-03-27 Thread Pavol Rusnak
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

2014-03-27 Thread Pavol Rusnak
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

2014-03-27 Thread Pavol Rusnak
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

2014-03-12 Thread Pavol Rusnak
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

2014-03-12 Thread Pavol Rusnak
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

2014-03-12 Thread Pavol Rusnak
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

2014-03-12 Thread Pavol Rusnak
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

2014-02-24 Thread Pavol Rusnak
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

2014-02-12 Thread Pavol Rusnak
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

2013-11-16 Thread Pavol Rusnak
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

2013-11-16 Thread Pavol Rusnak
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

2013-10-19 Thread Pavol Rusnak
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

2013-09-10 Thread Pavol Rusnak
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