Re: [Bitcoin-development] New BIP32 structure
On Wed, Mar 26, 2014 at 6:01 PM, Alan Reiner etothe...@gmail.com wrote: This might be tangential, but the comment about refund chains reminded me. Armory will be implementing multi-sig/linked wallets where a each device has a parallel HDW branch and produces P2SH addresses. For those types of wallets, I plan to allocate two chains *per signing authority*. If you have a shared 2-of-2 wallet split between your phone and your spouse's phone, your phone would distribute addresses on P2SH chain 0 and generate change addresses on P2SH chain 1. Your spouse's phone would use chains 2 and 3. So if you and your spouse switch to a new app that supports M-of-N linked wallets, it should search for coin history along the first 2*N chains. In general with multisig, we should probably discourage using a common root keychain for multiple keys in the same P2SH address. The reason is because if you have the single, root private key, you can sign them all. This generally goes against the point of multisig - which was trying to introduce a system which had multiple keys required to unlock :-) For the BitGo BIP32 implementation we are doing the following: - users create 2 extended keys - bitgo creates 1 extended key for that user - the user can create any number of separate branches (accounts) of P2SH addresses from those extended keys. - change/public addresses are generated from the 0/1 branches - new addresses are generated from there. - each time a new change address is generated, all 3 keys in the P2SH are rotated. This makes it so that for any chain depth *i* of the P2SH address, we're using the *i*th key in each keychain. For privacy reasons, we don't need to rotate all keys. But I think it makes management simpler and probably more ready for interop. So the paths in a user's keychain look exactly like BIP32's layout: m/AccountIndex/ExternalOrInternal/AddressIndex Another issue unique to P2SH addresses is order of the keys. There has been talk in this list of how to sort them. While sorting is simplifying for interop if you never use new change addresses, I believe sorting makes wallet management more difficult when BIP32 is introduced. Specifically, imagine a P2SH address with keys held by Bob, Charlie, and Dana. If you sort the pubkeys, then with each BIP32 chain, the order of the keys could be different. By maintaining key order, we always know which of the pubkeys belongs to which user without having to do any lookups. Obviously this can all be calculated too. But the sorting seems gratuitous to me - it adds complexity but offers little value. On the other hand, it can be really handy to know that key #0 for this address is always Bob's key, regardless of how deep the chaining goes. Mike -Alan On 03/26/2014 07:37 PM, Andreas Schildbach wrote: Thanks for starting the discussion on finding a better structure. For me, the most important thing is either we're 100% interoperable or 0%. There should not be anything inbetween, as users will delete seeds without knowing there is still money in them on another implementation. I heard from multiple sources that using this standard some wallets will only see a subset of the addresses/keys of some other wallets. Implementation differences can always happen (and should addresses as bugs), but I think its unacceptable that this source of issues is by design. I suggest we agree on an even simpler least common denominator and wallets that want to implement some feature on top of that can do but are encouraged to pick a totally different cointype. I guess that would mean removing reserved and account. I'm still thinking it might be a good idea to have a separate chain for refunds. Refunds will be rarely used and thus need a much slower moving window than receiving addresses or change. On 03/26/2014 09:49 PM, Mike Hearn wrote: Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure. Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with: /m/cointype/reserved'/account'/change/n The extra levels require some explanation: * 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 do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't. More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra
Re: [Bitcoin-development] New BIP32 structure
We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas Blummer, Tamas Bartfai (Bits of Proof) at the Inside Bitcoin Conference in Berlin. I remember that there were different opinions on how to use a hierarchy and it did seem to me they could eventually be standardized for the retail customer but definitelly not for corporate use, where hierarchy will certainly map to organisational hierarchy or cost centres. 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. Regards, Tamas Blummer http://bitsofproof.com On 26.03.2014, at 21:49, Mike Hearn m...@plan99.net wrote: Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure. Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with: /m/cointype/reserved'/account'/change/n The extra levels require some explanation: 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 do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't. More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra protocol layers involved in this, it can still import the raw money and it will just ignore/not see the keys used in more complex transactions. reserved is for other stuff. I actually don't recall why we ended up with this. It may have been intended to split out multisig outputs etc from cointype. Marek, Thomas? account is for keeping essentially wallets-within-a-wallet to avoid mixing of coins. If you want that. change is 0 for receiving addresses, 1 for change addresses. n is the actual key index For bitcoinj we're targeting a deliberately limited feature set for hdw v1 so I would just set the first three values all to zero and that is a perfectly fine way to be compatible. The goal here is that the same seed can be written down once, and meet all the users needs, whilst still allowing some drift between what wallets support. Pieter made the I think valid point that you can't really encode how keys are meant to be used into just an HDW hierarchy and normally you'd need some metadata as well. However, I feel interop between wallets is more important than arriving at the most perfect possible arrangement, which feels a little like bikeshedding, so I'm happy to just go with the flow on this one. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
At this point I'm not sure how much further work people want to do on this: I got the impression that Trezor will ship soon, and Thomas V seemed satisfied too. I'm not sure we can get all wallets to be fully interoperable given the flexibility inherent in BIP32 and people's differing use cases. Andreas: good point but I really hope nobody ever deletes a seed after all this work we put in to make backups so easy! I'm not sure we can really stop it anyway: not unless we make the seed a full blown data structure with hints to other apps that they should refuse to load it. And it's a bit late for that now. On Thu, Mar 27, 2014 at 8:09 AM, Tamas Blummer ta...@bitsofproof.comwrote: We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas Blummer, Tamas Bartfai (Bits of Proof) at the Inside Bitcoin Conference in Berlin. I remember that there were different opinions on how to use a hierarchy and it did seem to me they could eventually be standardized for the retail customer but definitelly not for corporate use, where hierarchy will certainly map to organisational hierarchy or cost centres. 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. Regards, Tamas Blummer http://bitsofproof.com On 26.03.2014, at 21:49, Mike Hearn m...@plan99.net wrote: Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure. Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with: /m/cointype/reserved'/account'/change/n The extra levels require some explanation: - 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 do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't. More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra protocol layers involved in this, it can still import the raw money and it will just ignore/not see the keys used in more complex transactions. - reserved is for other stuff. I actually don't recall why we ended up with this. It may have been intended to split out multisig outputs etc from cointype. Marek, Thomas? - account is for keeping essentially wallets-within-a-wallet to avoid mixing of coins. If you want that. - change is 0 for receiving addresses, 1 for change addresses. - n is the actual key index For bitcoinj we're targeting a deliberately limited feature set for hdw v1 so I would just set the first three values all to zero and that is a perfectly fine way to be compatible. The goal here is that the same seed can be written down once, and meet all the users needs, whilst still allowing some drift between what wallets support. Pieter made the I think valid point that you can't really encode how keys are meant to be used into just an HDW hierarchy and normally you'd need some metadata as well. However, I feel interop between wallets is more important than arriving at the most perfect possible arrangement, which feels a little like bikeshedding, so I'm happy to just go with the flow on this one. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
But these cases are the norm, rather than the exception. Well, you're lucky, you live in Berlin. Most of the payments I make with Bitcoin are online, to websites. So this will differ between people. I wonder how critical it is. Let's say you are paying for a meal. In your head the place you're at is just the little Indian restaurant on the corner. In the companies register and therefore certificate it's something like Singh Food GmbH. That's probably good enough to prevent shenanigans. Even if there's a virus on your phone, it can't really replace the cert with a random stolen one, otherwise your meal could show up like IronCore Steel Inc or something that's obviously bogus. It'd have to be an incredibly smart virus that knew how to substitute one name for a different one, from a large library of stolen identities, such that the swap seemed plausible. That sounds very hard, certainly too hard to bother with for stealing restaurant fees. And if a waiter at the restaurant is corrupt and they replace the cert with one that's for their own 1-man business BP-Gupta or something, OK, you might pay the wrong person by mistake. But eventually the corrupt waiter will be discovered and then someone will have proof of what they did. It's FAR more likely they'd just strip the signature entirely and try to convince you the restaurant doesn't use BIP70 at all. Still, if we want to fix this, one approach I was thinking about is to have a super-cheesy CA just for us that issues certs with addresses in them, for any name you ask for. That is, if you say you want a cert for Shamrock Irish Pub, Wollishofen, Zurich, CH then it either sends a postcard to that address with a code to check ownership of the address, or it checks ownership of the place on Google Maps (which does the same postcard trick but for free!). That doesn't work for vending machines, but perhaps we just don't care about those. If a MITM steals your lunch money, boo hoo. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
Le 27/03/2014 00:37, Andreas Schildbach a écrit : Thanks for starting the discussion on finding a better structure. For me, the most important thing is either we're 100% interoperable or 0%. There should not be anything inbetween, as users will delete seeds without knowing there is still money in them on another implementation. I believe you have a good point here: we should not advertise wallets as compatible if they are not 100% compatible. One issue that I have is bandwidth: Electrum (and mycelium) cannot watch as many addresses as they want, because this will create too much traffic on the servers. (especially when servers send utxo merkle proofs for each address, which is not the case yet, but is planned) For this reason Electrum imposes a constraint on the number of virgin addresses provided to the user. Although the current strategy used by Electrum can certainly be improved, it will not scale up to having every client watching thousands of addresses. This constraint is not so important for bloom-filter clients. So I guess that it makes sense for Multibit to provide hundreds, or even thousands of virgin addresses to the user, regardless of how they are used. Such a wallet will in general not be recoverable in Electrum, unless the user helps the recovery procedure. (or the seed has metadata telling the software that this is a Multibit wallet). So we have a problem here, if we advertise these wallets as compatible. My opinion, as far as Electrum is concerned, is that merchant accounts should behave differently from regular user accounts: While merchants need to generate an unlimited number of receiving addresses, it is also acceptable for them to have a slightly more complex wallet recovery procedure (for example, the wallet might show an option to search for more addresses, and it might not need to watch old addresses anymore) OTOH, I don't think we can ask regular users to do this, not only because it adds complexity to the wallet recovery procedure (which makes it scarier), but also because we want fully automated synchronization between different instances of a wallet, using only no other source of information than the blockchain. The first versions of Electrum allowed users to set the gap limit parameter in their GUI preferences, but I removed it from GUI after I realized it was a bad idea (users messed with it and did not understand what happened..) With bloom filter clients I guess the distinction between these two use cases is not really necessary, because watching addresses is cheap. So it would be good to hear what you and Mike think about this problem. If you decide to let the user create hundreds of unused addresses (and I think it perfectly makes sense for you), then I guess it would be better for Electrum to give up on compatibility, rather than running the risk of seeing only a subset of addresses. Another option is to handle these seeds as merchant accounts. I heard from multiple sources that using this standard some wallets will only see a subset of the addresses/keys of some other wallets. Implementation differences can always happen (and should addresses as bugs), but I think its unacceptable that this source of issues is by design. I suggest we agree on an even simpler least common denominator and wallets that want to implement some feature on top of that can do but are encouraged to pick a totally different cointype. I guess that would mean removing reserved and account. I'm still thinking it might be a good idea to have a separate chain for refunds. Refunds will be rarely used and thus need a much slower moving window than receiving addresses or change. On 03/26/2014 09:49 PM, Mike Hearn wrote: Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure. Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with: /m/cointype/reserved'/account'/change/n The extra levels require some explanation: * 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 do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't. More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra protocol layers involved in this, it can still import the raw money and it will just ignore/not see the keys used in more complex transactions.
Re: [Bitcoin-development] New BIP32 structure
Le 26/03/2014 21:49, Mike Hearn a écrit : * reserved is for other stuff. I actually don't recall why we ended up with this. It may have been intended to split out multisig outputs etc from cointype. Marek, Thomas? yes, this was intended to create multisig addresses from the same seed. cointype was proposed after that. -- ___ 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
One issue that I have is bandwidth: Electrum (and mycelium) cannot watch as many addresses as they want, because this will create too much traffic on the servers. (especially when servers send utxo merkle proofs for each address, which is not the case yet, but is planned) This is surprising and the first time I've heard about this. Surely your constraint is CPU or disk seeks? Addresses are small, I find it hard to believe that clients uploading them is a big drain, and mostly addresses that are in the lookahead region won't have any hits and so won't result in any downloads? This constraint is not so important for bloom-filter clients. Bloom filters are a neat way to encode addresses and keys but they don't magically let clients save bandwidth. A smaller filter results in less upload bandwidth but more download (from the wallets perspective). So I'm worried if you think this will be an issue for your clients: I haven't investigated bandwidth usage deeply yet, perhaps I should. FWIW the current bitcoinj HDW alpha preview pre-gens 100 addresses on both receive and change branches. But I'm not sure what the right setting is. We also have to consider latency. The simplest implementation from a wallets POV is to step through each transaction in the block chain one at a time, and each time you see an address that is yours, calculate the next ones in the chain. But that would be fantastically slow, so we must instead pre-generate a larger lookahead region and request more data in one batch. Then you have to recover if that batch ends up using all the pre-genned addresses. It's just painful. My opinion, as far as Electrum is concerned, is that merchant accounts should behave differently from regular user accounts: While merchants need to generate an unlimited number of receiving addresses, it is also acceptable for them to have a slightly more complex wallet recovery procedure Maybe. I dislike any distinction between users and merchants though. I don't think it's really safe to assume merchants are more sophisticated than end users. but also because we want fully automated synchronization between different instances of a wallet, using only no other source of information than the blockchain. I think such synchronization won't be possible as we keep adding features, because the block chain cannot sync all the relevant data. For instance Electrum already has a label sync feature. Other wallets need to compete with that, somehow, so we need to build a way to do cross-device wallet sync with non-chain data. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
Le 27/03/2014 12:30, Marek Palatinus a écrit : Ah, I forget to two things, which should be into the BIP as well: a) Gap factor for addresses; as Thomas mentioned, although some software can watch almost unlimited amount of unused addresses, this is serious concern for lightweight or server-based wallets like Electrum or myTREZOR. myTREZOR currently uses gap factor 10, which is (from my experience so far) quite sane for most of users. Yes, I was planning to increase the number of available unused addresses to 10 or 20 in the bip32 version of Electrum. Related to this, here is another idea I would like to submit: Instead of using a gap limit (maximal number of consecutive unused addresses), I think we should get rid of the topology, and simply count the number of unused addresses since the beginning of the sequence. Indeed, the topology of the sequence of addresses is of no interest to the user. Users often misinterpret gap limit as the number of unused addresses available, so I think we should just give them what they want :) This is easier to understand, and it makes things more predictable, because the wallet will always display the same number of unused addresses (except when it is waiting for confirmations). -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
By the way, I just noticed that greenaddress.it is creating seeds that have 24 words instead of 12. Does anyone know what's up with that? They claim to be using BIP32 wallets so I wanted to see if they were using the default structure and if so, whether bitcoinj was compatible with it (before I switch to the one discussed here). But it seems we fall at the first hurdle ... On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin thoma...@gmx.de wrote: Le 27/03/2014 12:30, Marek Palatinus a écrit : Ah, I forget to two things, which should be into the BIP as well: a) Gap factor for addresses; as Thomas mentioned, although some software can watch almost unlimited amount of unused addresses, this is serious concern for lightweight or server-based wallets like Electrum or myTREZOR. myTREZOR currently uses gap factor 10, which is (from my experience so far) quite sane for most of users. Yes, I was planning to increase the number of available unused addresses to 10 or 20 in the bip32 version of Electrum. Related to this, here is another idea I would like to submit: Instead of using a gap limit (maximal number of consecutive unused addresses), I think we should get rid of the topology, and simply count the number of unused addresses since the beginning of the sequence. Indeed, the topology of the sequence of addresses is of no interest to the user. Users often misinterpret gap limit as the number of unused addresses available, so I think we should just give them what they want :) This is easier to understand, and it makes things more predictable, because the wallet will always display the same number of unused addresses (except when it is waiting for confirmations). -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
Obviously, SHA256 can't magically generate more entropy out of nothing, it just stretches whatever is put in. If your seed was only 32 bits then hashing wouldn't save you: every possible private key could easily be calculated in advance. On Thu, Mar 27, 2014 at 2:12 PM, Thomas Kerin thomas.ke...@gmail.comwrote: Isn't the length of the seed arbitrary anyway? Once decoded using whatever mnemonic implementation (electrums, or BIP0039) the bytestream is immediately passed to HMAC-SHA256 to generate the master key. No matter what your initial entropy is, it would be hashed anyway. On Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn m...@plan99.net wrote: Ah, BIP32 allows for a range of entropy sizes and it so happens that they picked 256 bits instead of 128 bits. I'd have thought that there is a right answer for this. 2^128 should not be brute forceable, and longer sizes have a cost in terms of making the seeds harder to write down on paper. So should this be a degree of freedom? On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn m...@plan99.net wrote: By the way, I just noticed that greenaddress.it is creating seeds that have 24 words instead of 12. Does anyone know what's up with that? They claim to be using BIP32 wallets so I wanted to see if they were using the default structure and if so, whether bitcoinj was compatible with it (before I switch to the one discussed here). But it seems we fall at the first hurdle ... On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin thoma...@gmx.dewrote: Le 27/03/2014 12:30, Marek Palatinus a écrit : Ah, I forget to two things, which should be into the BIP as well: a) Gap factor for addresses; as Thomas mentioned, although some software can watch almost unlimited amount of unused addresses, this is serious concern for lightweight or server-based wallets like Electrum or myTREZOR. myTREZOR currently uses gap factor 10, which is (from my experience so far) quite sane for most of users. Yes, I was planning to increase the number of available unused addresses to 10 or 20 in the bip32 version of Electrum. Related to this, here is another idea I would like to submit: Instead of using a gap limit (maximal number of consecutive unused addresses), I think we should get rid of the topology, and simply count the number of unused addresses since the beginning of the sequence. Indeed, the topology of the sequence of addresses is of no interest to the user. Users often misinterpret gap limit as the number of unused addresses available, so I think we should just give them what they want :) This is easier to understand, and it makes things more predictable, because the wallet will always display the same number of unused addresses (except when it is waiting for confirmations). -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
Le 27/03/2014 12:39, Mike Hearn a écrit : One issue that I have is bandwidth: Electrum (and mycelium) cannot watch as many addresses as they want, because this will create too much traffic on the servers. (especially when servers send utxo merkle proofs for each address, which is not the case yet, but is planned) This is surprising and the first time I've heard about this. Surely your constraint is CPU or disk seeks? Addresses are small, I find it hard to believe that clients uploading them is a big drain, and mostly addresses that are in the lookahead region won't have any hits and so won't result in any downloads? To be honest, I have not carried out a comprehensive examination of server performance. What I can see is that Electrum servers are often slowed down when a wallet with a large number (thousands) of addresses shows up, and this is caused by disk seeks (especially on my slow VPS). The master branch of electrum-server is also quite wasteful in terms of CPU, because it uses client threads. I have another branch that uses a socket poller, but that branch is not widely deployed yet. I reckon that I might have been a bit too conservative, in setting the number of unused receiving addresses watched by Electrum clients (until now, the default gap limit has always been 5). The reason is that, if I increase that number, then there is no way to go back to a smaller value, because it needs to be compatible with all previously released versions. However, Electrum servers performance has improved over time, so I guess it could safely be raised to 20 (see previous post to slush). In terms of bandwidth, I am referring to my Android version of Electrum. When it runs on a 3G connection, it sometimes takes up to 1 minute to synchronize (with a wallet that has hundreds of addresses). However, I have not checked if this was caused by addresses or block headers. This constraint is not so important for bloom-filter clients. Bloom filters are a neat way to encode addresses and keys but they don't magically let clients save bandwidth. A smaller filter results in less upload bandwidth but more download (from the wallets perspective). So I'm worried if you think this will be an issue for your clients: I haven't investigated bandwidth usage deeply yet, perhaps I should. FWIW the current bitcoinj HDW alpha preview pre-gens 100 addresses on both receive and change branches. But I'm not sure what the right setting is. Heh, may I suggest 20 in the receive branch? For the change branch, there is no need to watch a large number of unused addresses, because the wallet should try to fill all the gaps in the sequence of change. (Electrum does that. It also watches 3 unused addresses at the end of that sequence, in order to cope with possible blockchain reorgs causing gaps. As an extra safety, it also waits for 3 confirmations before using a new change address, which sometimes results in address reuse, but I guess a smarter strategy could avoid that). We also have to consider latency. The simplest implementation from a wallets POV is to step through each transaction in the block chain one at a time, and each time you see an address that is yours, calculate the next ones in the chain. But that would be fantastically slow, so we must instead pre-generate a larger lookahead region and request more data in one batch. Then you have to recover if that batch ends up using all the pre-genned addresses. It's just painful. My opinion, as far as Electrum is concerned, is that merchant accounts should behave differently from regular user accounts: While merchants need to generate an unlimited number of receiving addresses, it is also acceptable for them to have a slightly more complex wallet recovery procedure Maybe. I dislike any distinction between users and merchants though. I don't think it's really safe to assume merchants are more sophisticated than end users. well, it depends what we mean by merchant. I was thinking more of a website running a script, rather than a brick and mortar ice cream seller. :) but also because we want fully automated synchronization between different instances of a wallet, using only no other source of information than the blockchain. I think such synchronization won't be possible as we keep adding features, because the block chain cannot sync all the relevant data. For instance Electrum already has a label sync feature. Other wallets need to compete with that, somehow, so we need to build a way to do cross-device wallet sync with non-chain data. Oh, I was not referring to label sync, but only to the synchronization of the list of addresses in the wallet. Label sync is an Electrum plugin that relies on a centralized server. Using a third party server is acceptable in that case, IMO, because you will not lose your coins if the server fails.
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Companies can have a Cert with their name via CAcert. It requires some work though to get assured as an organisation. Did you already think about what CA is to be trusted or do users need to do that. The least good decision in my POV would be to accept OS/browser built in CAs only. Am 27.03.2014 um 11:08 schrieb Mike Hearn m...@plan99.net: But these cases are the norm, rather than the exception. Well, you're lucky, you live in Berlin. Most of the payments I make with Bitcoin are online, to websites. So this will differ between people. I wonder how critical it is. Let's say you are paying for a meal. In your head the place you're at is just the little Indian restaurant on the corner. In the companies register and therefore certificate it's something like Singh Food GmbH. That's probably good enough to prevent shenanigans. Even if there's a virus on your phone, it can't really replace the cert with a random stolen one, otherwise your meal could show up like IronCore Steel Inc or something that's obviously bogus. It'd have to be an incredibly smart virus that knew how to substitute one name for a different one, from a large library of stolen identities, such that the swap seemed plausible. That sounds very hard, certainly too hard to bother with for stealing restaurant fees. And if a waiter at the restaurant is corrupt and they replace the cert with one that's for their own 1-man business BP-Gupta or something, OK, you might pay the wrong person by mistake. But eventually the corrupt waiter will be discovered and then someone will have proof of what they did. It's FAR more likely they'd just strip the signature entirely and try to convince you the restaurant doesn't use BIP70 at all. Still, if we want to fix this, one approach I was thinking about is to have a super-cheesy CA just for us that issues certs with addresses in them, for any name you ask for. That is, if you say you want a cert for Shamrock Irish Pub, Wollishofen, Zurich, CH then it either sends a postcard to that address with a code to check ownership of the address, or it checks ownership of the place on Google Maps (which does the same postcard trick but for free!). That doesn't work for vending machines, but perhaps we just don't care about those. If a MITM steals your lunch money, boo hoo. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
To be honest, I have not carried out a comprehensive examination of server performance. What I can see is that Electrum servers are often slowed down when a wallet with a large number (thousands) of addresses shows up, and this is caused by disk seeks (especially on my slow VPS). Yes that sounds more like what I expected. In terms of bandwidth, I am referring to my Android version of Electrum. When it runs on a 3G connection, it sometimes takes up to 1 minute to synchronize (with a wallet that has hundreds of addresses). However, I have not checked if this was caused by addresses or block headers. An address is 160 bits. (1000 * 160) / 8 / 1024 = 19.5 kilobytes of data which 3G should be able to transfer in 1 second easily. Of course the encoding may not be optimal. But if it is, I suspect the issue is elsewhere. -- ___ 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
Le 27/03/2014 13:49, Mike Hearn a écrit : Ah, BIP32 allows for a range of entropy sizes and it so happens that they picked 256 bits instead of 128 bits. I'd have thought that there is a right answer for this. 2^128 should not be brute forceable, and longer sizes have a cost in terms of making the seeds harder to write down on paper. So should this be a degree of freedom? Here is what I understand: 2^128 iterations is not brute forcable today, and will not be for the foreseeable future. An EC pubkey of length n can be forced in approximately 2^(n/2) iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which are 256 bits, would require 2^128 iterations. This is why unused addresses (160 bits hash) are better protected than already used ones. However, people tend to believe that a public key of size n requires 2^n iterations. This belief might have been spread by this popular image: https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
Le 27/03/2014 14:44, Pavol Rusnak a écrit : 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). I agree with that. I was planning to do the same (no gap) Note: Maybe we could just look at the first address of each account, instead of the first 10 ? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
Good to hear the bip32 wallet structure is _so_ close to being standardised. For MultiBit HD, we have put in support for 12/18/24 words but have the UI 'suggest' to use 12. You can see this on the wallet creation wizard Gary recently blogged about: https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html There's a little combo for the seed length, with 12 as the default. @Thomas. You mention gaps. We are creating new addresses on the UI in a panel marked 'Request' where the user also types in a QR code label and a note to themselves. This gets stored away as a first class 'PaymentRequest'. The UI 'suggests' that each address is used once. There will be some gaps (where the payment request is never paid) but we aren't bulk creating addresses. I am hoping this shouldn't cause Electrum a problem. We are also storing a timestamp (the number of days since the genesis block) to help wallet restore but that is SPV specific. On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote: Le 27/03/2014 13:49, Mike Hearn a écrit : IP32 allows for a range of entropy sizes and it so happens that they picked 256 bits instead of 128 bits. I'd have thought that there is a right answer for this. 2^128 should not be brute forceable, and longer sizes have a cost in terms of making the seeds harder to write down on paper. So should this be a degree of freedom? Here is what I understand: 2^128 iterations is not brute forcable today, and will not be for the foreseeable future. An EC pubkey of length n can be forced in approximately 2^(n/2) iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which are 256 bits, would require 2^128 iterations. This is why unused addresses (160 bits hash) are better protected than already used ones. However, people tend to believe that a public key of size n requires 2^n iterations. This belief might have been spread by this popular image: https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- http://bitcoin-solutions.co.uk -- ___ 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
For SPV wallets it's more complicated. There must always be a large lookahead window for latency reasons. We can't query the entire database because we don't know how far ahead the user is. So we have to assume there might be a lot of transaction traffic and create a large window, to reduce the chances that we run out whilst syncing and have to abort/restart the sync after resetting the Bloom filter. If you have a full db index then you can calculate some addresses, query, if they all get hits, calculate some more, requery, etc. It's a bit simpler. On Thu, Mar 27, 2014 at 2:58 PM, Jim jim...@fastmail.co.uk wrote: Good to hear the bip32 wallet structure is _so_ close to being standardised. For MultiBit HD, we have put in support for 12/18/24 words but have the UI 'suggest' to use 12. You can see this on the wallet creation wizard Gary recently blogged about: https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html There's a little combo for the seed length, with 12 as the default. @Thomas. You mention gaps. We are creating new addresses on the UI in a panel marked 'Request' where the user also types in a QR code label and a note to themselves. This gets stored away as a first class 'PaymentRequest'. The UI 'suggests' that each address is used once. There will be some gaps (where the payment request is never paid) but we aren't bulk creating addresses. I am hoping this shouldn't cause Electrum a problem. We are also storing a timestamp (the number of days since the genesis block) to help wallet restore but that is SPV specific. On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote: Le 27/03/2014 13:49, Mike Hearn a écrit : IP32 allows for a range of entropy sizes and it so happens that they picked 256 bits instead of 128 bits. I'd have thought that there is a right answer for this. 2^128 should not be brute forceable, and longer sizes have a cost in terms of making the seeds harder to write down on paper. So should this be a degree of freedom? Here is what I understand: 2^128 iterations is not brute forcable today, and will not be for the foreseeable future. An EC pubkey of length n can be forced in approximately 2^(n/2) iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which are 256 bits, would require 2^128 iterations. This is why unused addresses (160 bits hash) are better protected than already used ones. However, people tend to believe that a public key of size n requires 2^n iterations. This belief might have been spread by this popular image: https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- http://bitcoin-solutions.co.uk -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Thu, Mar 27, 2014 at 02:49:32PM +0100, Thomas Voegtlin wrote: Le 27/03/2014 13:49, Mike Hearn a écrit : Ah, BIP32 allows for a range of entropy sizes and it so happens that they picked 256 bits instead of 128 bits. I'd have thought that there is a right answer for this. 2^128 should not be brute forceable, and longer sizes have a cost in terms of making the seeds harder to write down on paper. So should this be a degree of freedom? Here is what I understand: 2^128 iterations is not brute forcable today, and will not be for the foreseeable future. I foresee 2^128 being brute forceable in 20-25 years. See below. An EC pubkey of length n can be forced in approximately 2^(n/2) iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which are 256 bits, would require 2^128 iterations. This is why unused addresses (160 bits hash) are better protected than already used ones. However, people tend to believe that a public key of size n requires 2^n iterations. This belief might have been spread by this popular image: https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146 So I assume this image is using the Landauer principle for minimum energy ( http://en.wikipedia.org/wiki/Landauer%27s_principle ), however it is unknown (to me at least) if a reversible computing ecdsa forcing algorithm could be implemented. (this may or may not be a quantum computing device) Let's suppose for a moment you could, and get a million times better than the Landauer pinciple limit of 2.85 zJ per bit, so we have total energy to cycle through 128 bits of address space of: units 2**128 * 2.85zJ / 1e6 megawatt*hours * 269.39021 An attacker with a sub-Landauer limit/1e6 cracker would need a lot of silicon area, and a couple of hours energy from a large wind farm, and could siphon that energy out in a rural area without anyone noticing anything other than a few shipping containers and that the wind turbines are running more on windy days. If we go back to just Landauer limit, and assume a 10MW system that runs 24x7 (much like the NCSA Blue Waters Cray machine), we need: (please check my math, or point out any stupid assumptions I've made) units 2**128 * 2.85zJ / 10 megawatts years * 3073.1914 Or 3000 years. Well that still sounds pretty safe. How about 250MW? units 2**128 * 2.85zJ / 250 megawatts years * 122.92766 Now I'm starting to get worried, because when I started computing, it was on an 8-bit CPU that was measured in thousand operations-per-second. In 1996 the largest supercomputer in the world was ASCII Red, with an amazing 1 trillion floating-point operations per second. This morning I have a 1-2 Teraflop water-cooled graphics processor sitting next to me warming the room. I expect in 5-10 years we'll have silicon with 256 bit registers that may be able to do thousands or millions of ECDSA calculations per second per computation unit. So if you stop hearing from me here, it's because I found a better mailing list, or a got a contract to develop and ECDSA cracker, in which case you probably won't hear from me again until I have a talk at DEFCON showing it off. -- Troy Benjegerdes -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
I think not all alts (will) have magic numbers, at least not those defined e.g. with colored coins on top of an other chain. Also note that the index should have MSB cleared as it would otherwise indicate private derivation. Regards, Tamas Blummer http://bitsofproof.com On 27.03.2014, at 16:57, Allen Piscitello allen.piscite...@gmail.com 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? -Allen On Thu, Mar 27, 2014 at 10:43 AM, Jeff Garzik jgar...@bitpay.com wrote: On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer ta...@bitsofproof.com 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. +1 good idea -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ 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
The idea was to use the magic number as the source for cointype. If it's too big, as Tamas showed, perhaps a hash of it, and for coins without a magic number, a hash of their name (or some unique identifier). That being said, I agree with Andreas that something that is 90% inter-operable seems very dangerous and will give people false expectations when they miss the corner cases. If the structure isn't going to be shared completely and have all support shared, having it completely incompatible along with a mechanism for converting part of it to another wallet seems superior. The worst types of losses will occur when someone tests out something with a limited use case, sees that it appears to work, makes dangerous assumptions, then gets burned when it's too late. -Allen On Thu, Mar 27, 2014 at 11:06 AM, Pavol Rusnak st...@gk2.sk wrote: 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
I'll make sure I understand your proposal better before commenting much on it, but at a first glance, I don't see how it is incompatible with 2 way peg and merged mining itself. Why wouldn't you want merged mining for the root of your tree? A miner could only chose a leaf block at a time, but it could merged mine with other leafs in other independent trees. Anyway, I'll better comment on the 2 way peg and merged mining issues raised so far. On 3/25/14, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach m...@monetize.io wrote: More importantly, to your last point there is absolutely no way this scheme can lead to inflation. The worst that could happen is theft of coins willingly put into the pegging pool. But in no way is it possible to inflate the coin supply. I don't think it would be entirely unfair to describe one of the possible ways a secondary coin becoming unbacked can play out as inflation-- after all, people have described altcoins as inflation. In the worst case its no _worse_ inflation, I think, than an altcoin is-- however. I think that's an obscure corner case that is not likely going to ever be implemented. If you produce real inflation there will likely be a bank run. If you're going to implement something equivalent to demurrage you should call it demurrage instead of inflation. And that's only for the pegged coin in the side chain: BITCOINS IN THE MAIN CHAIN WILL NEVER BE INFLATED USING 2P2. So I think it's less confusing if we just say that 2-way peg can't produce inflation in general, and leave unless you explicitly introduce an inflation mechanism as a probably unnecessary clarification. I see your point, but gmaxwell accurately guesses below that when I'm talking about inflation, I'm including the inflation of the alt too. You don't need inflation on the side chain. You don't need to create another currency to create another chain with different and maybe experimental features, that's the whole point. With merged mining, you're adding up the different created seigniorage subsidies to the same fire to share the heat. With 2-way peg, you don't even need to create a new p2p currency with a seigniorage to burn on hashes or be accused of pre-mining as the more ecological alternative in existence. Your chain can secure itself on fees, just like bitcoin in the future. Merged mining will help, but it's not the panacea and you will need to reward miners because that's what your security ultimately depends on. This is mostly about not burning the world, it may not be as interesting to you as improving bitcoin's scalability but you're not doing anyone a favor by presenting both concepts as being incompatible, not even yourself. With tree-chains that's particularly obvious as the scheme doesn't try to privilege one chain over another beyond parent-child relationships. If I understand it correctly, all the utxo nodes in the tree implement the same rules so doesn't seem suitable to solve the same problems. I understand that merged mining IS NOT a solution to scalability on its own, having 10 independent 1MB blocks is no worse than 1 10MB block in terms of performance vs centralization. But maybe it's possible to have a 10 GB sharded side-chain (your proposal) that it's merged mined with the main chain and where the currency of the side-chain comes from. So merged mining could help solve the scalability problem indirectly. And 2-way peg could be a useful previous step for your proposal to be deployed on production, with real bitcoins without forcing all bitcoin users to take the associated risks, only the people who opt in. Incidentally, I understand that the pegged chains are meant to be merge-mined. 2 way peg doesn't require merged mining but it is assumed that merged mining will be used since it provides more security than independent mining. I thought you agreed with this and your claim was just that merged mining is less secure than embedded consensus, something I have never denied, my complain against embedded consensus is that it doesn't seem to scale (with Bitcoin as it is today) and can't offer many features that a hardfork merged mined chain could offer (like those explained on our freimarkets proposal). But since you're implying again that merged mining is superior to independent mining is generally false, I invite you again to dismantle my example http://sourceforge.net/p/bitcoin/mailman/message/31806950/ or to prove your hypothesis that is free to attack merged mining chains by attacking namecoin for free. Either one will serve, my you're not responding to any of the suggestions. Instead, you're saying that people defending merged mining assume that attackers are economically rational. I think you're referring to me and it's false. Of course the attacker doesn't need to be economically rational. For some unknown reason he's attacking a chain, without questioning the rationality of the attack, I just sum costs,
Re: [Bitcoin-development] New BIP32 structure
Just chiming in... I'm not opposed to a more generic default key tree, but we need to standardize this soon I believe. There are already existing code bases that implement BIP32 wallets (and more are popping up...); just using a separate one will result in lots of incompibilities. 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 applications/p2p it should always be known to which chain it applies, and outside of that you shouldn't transfer raw keys. Maybe seeds need some marker, but that's a separate case anyway. Mainnet and testnet have specified magics here already - alts can define what they want imho. A 'reserved' field for future extensions may be useful, but as already suggested by Mike, I don't believe we can encode how key chains are to be used inside the derivation structure anyway. The most basic case (not losing money in a wallet without special structure) can perhaps be supported with just the blockchain is your wallet, but I don't believe this principle can scale to more advanced uses anyway, and you need metadata in the wallet to deal with it. In my view, your wallet just has a bunch of chains, and each chain gets used for a particular purpose, fixing how the derivation beneath it works. Either that is as a wallet, as part of a pair of multisig keys, as a recurring payment receiver, ... or more complex things. Some of these will require extra layers beneath, but that is application specific. You would import a chain into your (advanced) wallet with a particular extpub/extpriv code, and some metadata on how to use it. Serialization formats for such designated extra uses sounds better to me than trying to fit it into the derivation structure. -- Pieter On Thu, Mar 27, 2014 at 4:57 PM, Allen Piscitello allen.piscite...@gmail.com 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? -Allen On Thu, Mar 27, 2014 at 10:43 AM, Jeff Garzik jgar...@bitpay.com wrote: On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer ta...@bitsofproof.com 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. +1 good idea -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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] New BIP32 structure
On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak st...@gk2.sk wrote: Cointype in path is for separation purposes, not for identification. I don't understand what that gains you. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
The benefit I see is avoiding reuse of keys between coins while not having each wallet implementation have to know about each coin in order to scan for transactions. Wallet X supports Doge and Bitcoin. If both used a shared sequence of keys, say the first two end up Bitcoin, then 10 Doge, then some more Bitcoin. If you took this seed to Wallet Y, which only supports Bitcoin (either the wallet's support or what is installed on the system it's being used), it will see a gap of 10 addresses, and presume no more scanning with a 5 gap limit. The alternative is to reuse keys for each coin. It also seems like a solution might be to only expect interoperability on a single sequence, and provide backups of each final sequence to use between different wallet implementations. This allows flexibility in hierarchies depending on needs and support of wallet, but allows sharing. The short seed would only be useful for the same wallet, but sharing between wallets would use the longer keys. That will give predictable behavior for users (although less friendly) and lead to less errors. -Allen On Thu, Mar 27, 2014 at 11:28 AM, Pieter Wuille pieter.wui...@gmail.comwrote: On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak st...@gk2.sk wrote: Cointype in path is for separation purposes, not for identification. I don't understand what that gains you. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
