Re: [Bitcoin-development] Bip 32 Question
The `n` is the curve order, as shown here: https://en.bitcoin.it/wiki/Secp256k1 This step is necessary to keep you on the curve. The secp256k1_ec_privkey_tweak_add function from libsecp256k1 handles this automatically, but if you use OpenSSL or some non-EC math library, you probably have to do it yourself. -William On Fri, Jun 12, 2015 at 11:22 AM, James Poole wrote: > Looking at the BIP32 definition, I hit a line that I would appreciate > clarification on. > > https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki > > Under the section "Private parent key → private child key" there is a step: > > "The returned child key ki is parse256(IL) + kpar (mod n)." > > Can someone help me understand what "n" is in the context of this algorithm? > I very well could be looking right at it, but wanted to double check if I am > missing something. > > Thanks, > James -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
On Thu, Apr 16, 2015 at 9:12 AM, s7r wrote: > Thanks for your reply. I agree. Allen has a good point in the previous > email too, so the suggestion might not fix anything and complicate things. The BIP 62 approach to malleability isn't the only option. Another approach is to sign the transaction in such a way that the input txid's are allowed to change without invalidating the signatures. That way, if malleability happens, you just adjust you transaction to match and re-broadcast. That proposal is here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md The "Build your own nHashType" thread on this mailing list contains the discussion. I personally prefer this solution, since it nails the problem completely with one simple and obvious change. The BIP 62 approach is more like a game of wac-a-mole. -William -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets
Oops, sorry I missed that. Since that's the reason this proposal exists, I would consider putting it right up top where people can see it. Also, since this proposal is specifically designed for multi-sig, I would look at what BIP45 is doing and maybe incorporate a "cosigner_index" branch. Otherwise, this idea seems like a reasonable way to organize a wallet. -William On Wed, Apr 8, 2015 at 9:28 AM, 木ノ下じょな wrote: > William, > > I believe the reasoning for this is stated in the Coin Type section. > > "Public derivation is used so that cosigners need only know one of each > other's public keys, rather than needing to distribute public keys for each > coin." > > BIP44 has a coin level, but it's a private derived level, so cosigners would > not be able to generate multiple crypto currencies of each others' without > giving each other n xpubs where n is the number of currencies shared. This > new proposal basically sticks coin type on the public derivation side of > things so that I could generate litecoin or darkcoin multisigs without your > permission... > > Kefkius, > > This BIP seems like a good fit for multi-currency wallets based on multisig. > So kudos for putting it in writing. > > However, I don't know if this is really a BIP thing. It's not improving > Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definition > it is improving altcoin usability. > > For that reason alone I will say I disagree for a BIP for this. > - Jona > > > 2015-04-08 16:46 GMT+09:00 William Swanson : >> >> It's not really clear why this is better than BIP 44 as it already >> stands. You have the same fields, but they are just in a different >> order. Couldn't you just use the existing BIP 44 hierarchy, but add >> the convention that "wallet/account N" is the same wallet in each >> supported currency? >> >> For example, if I have a wallet called "business expenses", which >> happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same >> wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5' >> for Litecoin. >> >> I am trying to think of examples where your proposal is better than >> BIP 44, but I can't think of any. Even backup recovery works fine. I >> assume that your idea is to continue iterating over the different >> wallet indices as long as you are finding funds in *any* currency. >> Well, you can still do that with BIP 44. The fields are in a different >> order, but that doesn't affect the algorithm in any way. >> >> Maybe you have some deeper insight I'm not seeing, but if so, you need >> to clearly explain that in your motivation section. The current >> explanation, "This limits the possible implementations of >> multi-currency, multisignature wallets," is pretty vauge. Also, there >> is nothing in this spec that addresses the multisignature use-case. >> The BIP 45 spec does a lot of extra work to make multisignature work >> smoothly. >> >> I'm not trying to criticize your proposal. I'm just trying to >> understand what it's trying to accomplish. >> >> -William Swanson >> >> >> On Wed, Apr 8, 2015 at 12:05 AM, Kefkius wrote: >> > I have a potential BIP, "Multi-Currency Hierarchy For Use In >> > Multisignature Deterministic Wallets." I'm requesting discussion on it, >> > and possibly assignment of a BIP number. >> > >> > It's located in this github gist: >> > https://gist.github.com/Kefkius/1aa02945e532f8739023 -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets
It's not really clear why this is better than BIP 44 as it already stands. You have the same fields, but they are just in a different order. Couldn't you just use the existing BIP 44 hierarchy, but add the convention that "wallet/account N" is the same wallet in each supported currency? For example, if I have a wallet called "business expenses", which happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5' for Litecoin. I am trying to think of examples where your proposal is better than BIP 44, but I can't think of any. Even backup recovery works fine. I assume that your idea is to continue iterating over the different wallet indices as long as you are finding funds in *any* currency. Well, you can still do that with BIP 44. The fields are in a different order, but that doesn't affect the algorithm in any way. Maybe you have some deeper insight I'm not seeing, but if so, you need to clearly explain that in your motivation section. The current explanation, "This limits the possible implementations of multi-currency, multisignature wallets," is pretty vauge. Also, there is nothing in this spec that addresses the multisignature use-case. The BIP 45 spec does a lot of extra work to make multisignature work smoothly. I'm not trying to criticize your proposal. I'm just trying to understand what it's trying to accomplish. -William Swanson On Wed, Apr 8, 2015 at 12:05 AM, Kefkius wrote: > I have a potential BIP, "Multi-Currency Hierarchy For Use In > Multisignature Deterministic Wallets." I'm requesting discussion on it, > and possibly assignment of a BIP number. > > It's located in this github gist: > https://gist.github.com/Kefkius/1aa02945e532f8739023 > > -- > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil wrote: > A MITM can receive the initial broadcast and then spoof it by jamming the > original. You then only see one. You are right, of course. There is no way to make Bluetooth 100% secure, since it is an over-the-air technology. You could try securing it using a CA or other identity server, but now you've excluded ad-hoc person-to-person payments. Plus, you need an active internet connection to reach the CA. You can try using proximity as a substitute for identity, like requiring NFC to kick-start the connection, but at that point you might as well use QR codes. This BIP is not trying to provide absolute bullet-proof security, since that's impossible given the physical limitations of the Bluetooth technology. Instead, it's trying to provide the best-possible security given those constraints. In exchange for this, we get greatly enhanced usability in common scenarios. There are plenty of usable, real-world technologies with big security holes. Anybody with lock-picking experience will tell you this, but nobody is welding their front door shut. The ability to go in and out is worth the security risk. Bluetooth payments add a whole new dimension to real-world Bitcoin usability. Do we shut that down because it can't be made perfect, or do we do the best we can and move forward? -William -- 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] Serialised P2SH HD chains
Yes. A few of us over here in San Diego actually started working on a format like this a few months ago, but it's been on the back burner for a while. Our motivation was to come up with a shared HD wallet format. Say I would like create a 2-of-3 multisig wallet using my phone, PC, and hardware key fob. All three devices would presumably be running different wallet software, so we need some sort of standardized HD multisig chain-description format that all three wallets can understand. That way, regardless of their other differences, the wallets can at least agree on how to generate new addresses. Of course, once you share this chain-description file with a third party, they too can generate addresses out of the wallet. This can be used for auditing (like for charities), for receive-only wallets (like a merchant kiosk), and for recurring payments. The recurring payment case is a little problematic, since you need to trust the payee with your privacy. I imagine this would only be useful for payouts you manage yourself, like a mining pool, and not something you share with the general public. Our format is very similar to yours. We have a script template, just like you do, but we describe the HD chains in a separate section rather than in-line with the script. The script template only comes into being once the chains have been gathered together into one place, so the chain descriptions need to stand alone. Unfortunately, we still have a lot of details to work through before we have a concrete proposal that's ready for this mailing list. Perhaps we can work together to come up with something. -William On Thu, Dec 4, 2014 at 7:42 AM, Luke Dashjr wrote: > Is anyone working on a serialisation format to convey P2SH HD chains? For > example, to give someone who wants to make recurring payments a single token > that can be used to generate many P2SH addresses paying to a multisig script. > > I'm thinking of something along the lines of a simple series of tokens, each > indicating either a HD chain or literal script content. For all HD chains in > the data, a child key would be generated based on the payment number, and all > tokens concatenated to form the P2SH serialised script. Eg, for a simple 2- > of-2, you would do something like this: > literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG) > Does this sufficiently cover all reasonable use cases? > > Luke -- 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=164703151&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bip-0021 and bip-0072 ambiguities & mistakes
On Thu, Mar 6, 2014 at 2:59 PM, Mike Hearn wrote: > Yes please, pull req would be great! I also noticed that escaping doesn't > seem to be necessary, and the resultant de-escaped QRcodes are certainly > much nicer! Thanks! All right, I have submitted the pull request. Hopefully, the specified behavior now corresponds more closely to what the bitcoin-qt client is actually doing, and to what the RFC recommends. -William -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] bip-0021 and bip-0072 ambiguities & mistakes
Hello, I am attempting to write a parser for bip-0021 URI's, including support for the new bip-0072 payment parameters. My goal is absolute correctness. Unfortunately, these BIP's have a few ambiguities and mistakes which ought to be corrected. First, I would like to point out that internet RFC 3986 governs the general syntax for URI's. It obsoletes RFC 1738 and various other early RFC's. Since RFC 3986 came out in 2005, I think we can agree that any bitcoin URI scheme should use this and not the earlier ones. Unfortunately, bip-0021 never actually mentions RFC 3986, which is a big omission. Even worse, bip-0072 explicitly refers to RFC 1738, which is obsolete. This is a problem, since the old, obsolete standard requires more escapes than are actually necessary. Updating bip-0072 to refer to RFC 3986 instead would allow shorter, more readable bitcoin URI's (things like slashes in payment addresses wouldn't need to be escaped). Secondly, neither of the bip's describe what to do with international characters. I doubt anybody wants to limit the "label" and "message" parameters to 7-bit ASCII, so a character encoding needs to be defined. RFC reccomends that all new URI schemes use UTF-8 as their encoding, which is perfectly reasonable. The bip-0021 standard just needs to actually say so. Finally, there is an error in the bip-0021 BNF grammar, which never mentions the '&' separator between query elements. What is the procedure for getting these BIP's corrected? Submit a pull request with the changes? Hopefully we can all agree that these fixes are useful and necessary. -William P.S. The bitcoin-qt client uses QUrl to parse bitcoin uri's, and that is based on RFC 3986. Thus, the bitcoin-qt client is probably already implementing these suggestions. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
