Re: [Bitcoin-development] Block Size Increase
I don't have strong opinion @ block size topic. But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE ( https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All developers of lightweight (blockchain-less) clients will adore you! slush On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me wrote: Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Block size is a question to which there is no answer, but which certainly has a LOT of technical tradeoffs to consider. I know a lot of people here have varying levels of strong or very strong opinions about this, and the fact that it is not being discussed in a technical community publicly anywhere is rather disappointing. So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Matt [1] https://twitter.com/coinbase/status/595741967759335426 -- 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 -- 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] Electrum 2.0 has been tagged
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn m...@plan99.net wrote: - Electrum v2 with a version number but no date - myTREZOR with no version and no date and BIP44 key derivation. Some seeds I believe are now being generated with 24 words instead of 12. - MultiBit HD with no version and a date in a custom form that creates non-date-like codes you are expected to write down. I think BIP32 and BIP44 are both supported (sorta). - GreenAddress with no version, no date and BIP32 - Other bitcoinj based wallets, with no version and a date written down in normal human form, BIP32 only. To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD uses BIP44 with first account only and GreenAddress uses another scheme because it's multisig only wallet). I disagree with the need of some version magic flags or creation date stored in the mnemnonic, for those reasons: a) If we fail in the way how mnemonic algo is defined, then some magic, extra version flag won't save our asses, because we'll fail in meaning of its meaning. Then it will be completely useless, as implementations cannot rely on it. I know Thomas was sound proponent of this solution, but he was unable to give any reasonable rules about who/how define meaning of version flag. b) Creation date is just a short-term hack. Considering that mnemonic words are kind of cold storage (longterm storage), it *really* does not make much difference in 2020, if your wallet has been created in 02/2014 or 10/2016. If there's performance issue with scanning of the blockchain, creation date don't save our asses. We need to find another solution, and as a bonus, we don't need users to know some weird numbers on top of mnemonic itself. From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between wallet providers. There is some recommendations regarding the wordlists to help with things such as predictive text, so mobile apps can easily predict the word being typed in after a few chars etc. Exactly! After some community feedback, we changed BIP39 algo to be one-way only, which means you can use *any* wordlist to create the mnemonic, and any other implementation can derive BIP32 root node even without knowing that particular wordlist. Namely this has been changed because of constructive criticism of ThomasV, and from discussion on the mailing list I had a feeling that we've found a consensus. I was *very* surprised that Electrum 2.0 started to use yet another algo just because. Shortly said, I think BIP39 does perfect job and there's no need to use anything else. Cheers, Marek -- 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] SIGHASH_WITHINPUTVALUE
Oh, now I got the 'soft-fork' alternative. If that means that *senders* to Trezor need to be nice guys and use some special outputs, then it's, obviously, no-go solution. I understand political aspect around hard-fork. Anyway, are there any other pending projects waiting for hard-fork? Maybe we should join our effort in some way. M. On Fri, Jan 23, 2015 at 5:27 PM, Alan Reiner etothe...@gmail.com wrote: I am happy to entertain other ideas that achieve our goals here, but I'm fairly confident that the new SIGHASH type is the only way that would allow devices like Trezor to truly simplify their design (and still work securely on 100% of funds contained by the wallet). -- 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 -- 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
[Bitcoin-development] SIGHASH_WITHINPUTVALUE
Hi, is any progress or even discussion in this area? https://bitcointalk.org/index.php?topic=181734.0 I don't insist on any specific solution, but this is becoming a real issue as hardware wallets are more widespread. I'm sitting next to TREZOR for 40 minutes already, because it streams and validate some complex transaction. By using proposed solution, such signature would be a matter of few seconds. That's also not just about time/resource/hw cost optimization. I'm talking about possibility of huge simplification of the firmware (=security FTW), because 50% of actual codebase is solving this particular downside of Bitcoin protocol. So, there's real world problem. On which solution can we as a community find a wide agreement? Best, Marek -- 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] SIGHASH_WITHINPUTVALUE
I *strongly* encourage this to be considered for inclusion at some point. Thanks Alan for a nice summary. I also agree that such stuff should be implemented at some point. Anyway, I would probably not vote for doing hard fork *just* for this change, but if I remember well, there're other ideas flying around in the air and waiting for hardfork... Marek On Fri, Jan 23, 2015 at 4:24 PM, Alan Reiner etothe...@gmail.com wrote: The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise non-intrusive, doesn't change any TxOut scripts, doesn't change any tx/block parsing (besides verification), it works with all existing coins in the network, and existing software doesn't have to use it if they don't want to upgrade their signers. The proposal simply provides a way to optionally sign the input values with the TxOut scripts. In other words a signature right now says I sign this transaction using these inputs, whatever value they are. With this SIGHASH type, the signature says I sign this transaction assuming that input 0 is X BTC, input 1 is Y BTC,. If the online computer providing the data to be signed lies about the value of any input, the resulting signature will be invalid. Unfortunately, it seems that there was no soft-fork way to achieve this benefit, at least not one that had favorable properties. Most of the soft-fork variations of it required the coins being spent to have been originated in a special way. In other words, it would only work if the coins had entered the wallet with some special, modified TxOut script. So it wouldn't work with existing coins, and would require senders to update their software to reshape the way they send transactions to be compatible with our goals. I *strongly* encourage this to be considered for inclusion at some point. Not only does it simplify HW as Marek suggested, it increases the options for online-offline communication channels, which is also a win for security. Right now, QR codes don't work because of the possibility of having to transfer megabytes over the channel, and no way to for the signer to control that size. With this change, it's possible for the signer to control the size of each chunk of data to guarantee it fits in, say, a QR code (even if it means breaking it up into a couple smaller transactions). -Alan On 01/23/2015 09:51 AM, slush wrote: Hi, is any progress or even discussion in this area? https://bitcointalk.org/index.php?topic=181734.0 I don't insist on any specific solution, but this is becoming a real issue as hardware wallets are more widespread. I'm sitting next to TREZOR for 40 minutes already, because it streams and validate some complex transaction. By using proposed solution, such signature would be a matter of few seconds. That's also not just about time/resource/hw cost optimization. I'm talking about possibility of huge simplification of the firmware (=security FTW), because 50% of actual codebase is solving this particular downside of Bitcoin protocol. So, there's real world problem. On which solution can we as a community find a wide agreement? Best, Marek -- 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 listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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 T -- 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] SIGHASH_WITHINPUTVALUE
Correct, plus the most likely scenario in such attack is that the malware even don't push such tx with excessive fees to the network, but send it directly to attacker's pool/miner. M. On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner etothe...@gmail.com wrote: Unfortunately, one major attack vector is someone isolating your node, getting you to sign away your whole wallet to fee, and then selling it to a mining pool to mine it before you can figure why your transactions aren't making it to the network. In such an attack, the relay rules aren't relevant, and if the attacker can DoS you for 24 hours, it doesn't take a ton of mining power to make the attack extremely likely to succeed. On 01/23/2015 10:31 AM, Tamas Blummer wrote: Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions. Tamas Blummer -- 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 -- 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] SIGHASH_WITHINPUTVALUE
On Fri, Jan 23, 2015 at 5:05 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I think this is unreasonable. There is a straight-forward soft-fork approach which is safe (e.g. no risk of invalidating existing transactions). Yes, it means that you need to use newly created addresses to get coins that use the new signature type... Can you send me any reference about this? Of course if that solves the problem, hard fork would not be necessary anymore. I'm just not aware of any. Can you help me understand whats taking 40 minutes here? Thats a surprisingly high number, and so I'm wondering if I'm not missing something there. To sign transaction with hundreds of inputs on device with limited memory capabilities, I need to stream all previous transactions into device, for every signed input. That means roughly 200^2 transaction verifications for 200 inputs to sign. Very slow, but does not limit the device for any particular size of signed transaction. Marek -- 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] Miners MiTM
AFAIK the only protection is SSL + certificate validation on client side. However certificate revocation and updates in miners are pain in the ass, that's why majority of pools (mine including) don't want to play with that... slush On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr l...@dashjr.org wrote: On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote: Hi there, I was wondering if you guys have come across this article: http://www.wired.com/2014/08/isp-bitcoin-theft/ The TL;DR is that somebody is abusing the BGP protocol to be in a position where they can intercept the miner traffic. The concerning point is that they seem to be having some degree of success in their endeavour and earning profits from it. I do not understand the impact of this (I don't know much about BGP, the mining protocol nor anything else, really), but I thought it might be worth putting it up here. This is old news; both BFGMiner and Eloipool were hardened against it a long time ago (although no Bitcoin pools have deployed it so far). I'm not aware of any actual case of it being used against Bitcoin, though - the target has always been scamcoins. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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] Miners MiTM
Although 140 BTC sounds scary, actually it was very minor issue and most of miners aren't even aware about it. TLS would probably make the attack harder, that's correct. However if somebody controls ISP routers, then MITM with TLS is harder, yet possible. slush On Fri, Aug 8, 2014 at 3:07 AM, Pedro Worcel pe...@worcel.com wrote: Seems to me that it would correctly mitigate the attack mentioned in the wired article. I am surprised that miners are not worried about losing their profits, I would personally be quite annoyed. -- 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] Decentralizing ming
On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik jgar...@bitpay.com wrote: Historical note: On one hand, Satoshi seemed to dislike the early emergence of GPU mining pools quite a bit. To my knowledge, Satoshi left the project before mining pools got a traction. slush -- 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] Proposed BIP 70 extension
On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn m...@plan99.net wrote: The protocol is there to contain features! There is zero benefit to slavishly following some religious notion of purity or minimalism here. Good standard must be explicit as much as possible. Having million optional fields with ambiguous meaning is even worse than not having these fields. HTTP status codes are good example. There are hundreds of them, still applications understands just few of them, because other have ambiguous meaning and software don't know how to handle them. Good example of such over-engineering is also XMPP. XMPP has milions extensions and features, but look at Jabber clients; call yourself lucky when you can send messages and files, although there're various extensions like searching for contacts (something which has be working in ICQ decade ago), voice support, end to end encryption or alerting users. These features are defined, but not widely implemented, because its definition is vague or the feature is abused because of poor design. Please don't over-engineer payment protocol. Thank you for your attention. slush -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
Sounds like marketing bullshit to me. It does not have even statistical meaning; well, you can save a lot of satoshis, but nobody tell you that the merchant cut you on BTC/USD exchange rate in tens of %. Payment protocol should not contain these fictional data, which has no real meaning for the payment itself. Put these marketing claims to memo field instead... slush On Tue, Jun 24, 2014 at 4:24 PM, Mike Hearn m...@plan99.net wrote: It also seems like it would be subject to instant inflation, as it's unprovable The user knows the price that is on the website or menu, they know the price they actually paid ... if the numbers don't add up that would seem to be pretty easily detectable. But sure it's only for marketing. I think the comment makes it clear it's just for fun. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:
On Thu, Jun 19, 2014 at 7:35 PM, Mike Hearn m...@plan99.net wrote: My (fresh!) understanding is that the reason we don't see people using getblocktemplate to decentralise pools is because libblkmaker and other implementations don't actually support connecting your own node to the miners and choosing your own blocks, even though the protocol does. Well, I don't want to start flamewar (and this topic has potential!), but the *real* reason why there isn't such infrastructure is that although GBT as a protocol *does* support of decentralized building of blocks, it is *extremely* resource consuming to validate these shares on pool side. With GBT, simply hashing the block header is not enough, because pool cannot rely on anything provided by the client. Its not only about things like withdrawal attacks, but more about hidden bugs in various miners. It is extremely hard to do full validation for *every* of submitted shares. Although I see benefits of GBT and I see limits of Stratum, I don't think that supporting full GBT validation have economic sense for any medium sized pool, because such pool would need multiply his running costs on servers many times. It's part of a general trend wherein people look at all the things that can be accomplished in an economy that has a division of labor*, and see some misbehavior at the edges, and decide that rather than fixing the misbehavior we should throw out the entire concept of labor specialization. Well written! This reminds me - what about Stratum + SPV validation on miner side? With SPV, miner cannot choose his own transactions, so it is not fully decentralized, but at least miner can detect (in real time) two major pool misbehaviours - selfish mining (building private blockchain) and chain forking (not working on longest known blockchain). I read such proposal about Stratum + SPV on reddit and I actually like it; It removes major drawbacks of centralized Stratum mining, yet is gives tools to miners to instantly switch to fallback pool when something wrong is happening. slush -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:
Miner issues are just one thing what came to my mind. What about validating transactions? How the pool can be sure that miner is running up to date bitcoind which do full validation of transactions? Not talking that if every miner takes his own set of transaction, pool need to calculate merkle root for every submit, to check its correctness. I don't think it *cannot* be done, it is just extremely hard and there's no economic motivation for such complication on pool side. Just see current pools, they are full of security and stability bugs even while using such trivial protocol like Stratum... slush On Thu, Jun 19, 2014 at 10:39 PM, Mark Friedenbach m...@monetize.io wrote: Do you need to do full validation? There's an economic cost to mining invalid blocks, and even if that were acceptable there's really no reason to perform such an attack. The result would be similar to a block withholding attack, but unlike block withholding it would be trivially detectable if/when full validation was performed. To protect yourself and to detect incorrect mining software you could stochastically validate a randomly selected sample of shares, as your hardware requirements allow. On 06/19/2014 01:26 PM, slush wrote: With GBT, simply hashing the block header is not enough, because pool cannot rely on anything provided by the client. Its not only about things like withdrawal attacks, but more about hidden bugs in various miners. It is extremely hard to do full validation for *every* of submitted shares. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bits: Unit of account
Excellent points Christophe! Although moving to 1e-6 units is fine for me and I see advantages of doing this, I don't get that people on this mailing list are fine with calling such unit bit. It's geeky as hell, ambiguous and confusing. slush On Sat, May 3, 2014 at 5:48 PM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? On Sat, May 3, 2014 at 1:41 AM, Aaron Voisine vois...@gmail.com wrote: I have to agree with Mike. Human language is surprisingly tolerant of overloading and inference from context. Neurotypical people have no problem with it and perceive a software engineer's aversion to it as being pedantic and strange. Note that bits was a term for a unit of money long before the invention of digital computers. Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, May 2, 2014 at 7:06 PM, Gordon Mohr goj...@gmail.com wrote: [resend - apologies if duplicate] Microbitcoin is a good-sized unit, workable for everyday transaction values, with room-to-grow, and a nice relationship to satoshis as 'cents'. But bits has problems as a unit name. Bits will be especially problematic whenever people try to graduate from informal use to understanding the system internals - that is, when the real bits of key sizes, hash sizes, and storage/bandwidth needs become important. The bit as binary digit was important enough that Satoshi named the system after it; that homage gets lost if the word is muddied with a new retconned meaning that's quite different. Some examples of possible problems: * If bit equals 100 satoshis, then the natural-language unpacking of bit-coin is 100 satoshi coin, which runs against all prior usage. * If people are informed that a 256-bit private key is what ultimately controls their balances, it could prompt confusion like, if each key has 256-bits, will I need 40 keys to hold 10,000.00 bits? * When people learn that there are 8 bits to a byte, they may think, OK, my wallet holding my 80,000.00 bits will then take up 10 kilobytes. * When people naturally extend bit into kilobits to mean 1000 bits, then the new coinage kilobits will mean the exact same amount (100,000 satoshi) as many have already been calling millibits. I believe it'd be best to pick a new made-up single-syllable word as a synonym for microbitcoin, and I've laid out the case for zib as that word at http://zibcoin.org. 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ' (Z-with-stroke), that remains distinctive even if it loses its stroke or gets case-reversed. (Comparatively, all 'b'-derived symbols for data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts where subtleties of casing/stroking are lost.) (There's summary of more problems with bit in the zibcoin.org FAQ at: http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins.) - Gordon On 5/1/14, 3:35 PM, Aaron Voisine wrote: I'm also a big fan of standardizing on microBTC as the standard unit. I didn't like the name bits at first, but the more I think
Re: [Bitcoin-development] New BIP32 structure
On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille pieter.wui...@gmail.comwrote: Storing the seed is superior to storing the master node already (whether coin specific or not), as it is smaller. ...Except that you're loosing flexibility (serialization, deserialization) which gives you BIP32 node. I see bip32 seed as some transitional, internal state from raw entropy to bip32 master node and this seed should not be handled by the end user in any form. In the oposite, well-serialized bip32 node (in xpriv, or even in mnemonic format) can be used very widely and have no downsides against using raw bip32 seed. Fair enough, it would break strictly BIP32. Then again, BIP32 is a *Bitcoin* improvement proposal, and not something that necessarily applies to other coins (they can adopt it of course, I don't care). I also don't care too much about altcoins, but people want them so me, as infrastructure developer, need to think about it. And I don't see any reason for breaking compatibility between Bitcoin and other altcoins. I would be happier if there will be another sentence than Bitcoin seed, but honestly, who cares. It is just some magic string for hashing the raw seed... What I dislike is that this removes the ability of using the magic in the serialization to prevent importing a chain from the wrong coin. The truth is that even existing software which handle bip32 don't care about 'version' at all. I think that xpub/xprv distinction is the only useful feature of version, so user se if it stores public or private information. But using prefixes which doesn't enforce anything is even more dangerous. If somebody exports node dogeblablabla, it creates false exceptations that there's only dogecoin stored. Marek -- 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
Using higher gap limit in the software is not prohibited, but then it breaks the standard as is, in mean that importing such wallet to another BIP64 wallet won't recover the funds properly, without proper settings of gap limit... Gap limit 20 is the most sane defaults for majority of users (actually I think it is a bit higher than is really necessary for 99% users) and majority of users won't need to change it at any time. Marek On Wed, Apr 23, 2014 at 9:00 PM, Tier Nolan tier.no...@gmail.com wrote: On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak st...@gk2.sk wrote: 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. I meant for a merchant with a server that is handing out hundreds of addresses. The point is to have a single system that is compatible over a large number of systems. -- 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 -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs are in the wallet, they are no longer associated with the address or any other details of how they were received. Wallet don't see UTXO until it scans all branches/accounts on HD node import. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wed, Apr 23, 2014 at 10:54 PM, Pieter Wuille pieter.wui...@gmail.comwrote: Would you consider software which scans all accounts as specified by BIP64, but has no user interface option to distinguish them in any way, view them independently, and has no ability to keep the coins apart... compatible with BIP64? No, because one of requirement of BIP64 is to do not mix addressess between accounts. Without handling those accounts fully, it won't pass this requirement. (This level [accounts] splits the key space into independent user identities, so the wallet never mixes the coins across different accounts.) Marek -- 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] Bitcoind-in-background mode for SPV wallets
I believe there're plenty bitcoind instances running, but they don't have configured port forwarding properly.There's uPNP support in bitcoind, but it works only on simple setups. Maybe there're some not yet considered way how to expose these *existing* instances to Internet, to strenghten the network. Maybe just self-test indicating the node is not reachable from outside (together with short howto like in some torrent clients). These days IPv6 is slowly deploying to server environments, but maybe there's some simple way how to bundle ipv6 tunnelling into bitcoind so any instance will become ipv6-reachable automatically? Maybe there're other ideas how to improve current situation without needs of reworking the architecture. Marek On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier justusranv...@gmail.com wrote: Anyone reading the archives of the list will see about triple the number of people independently confirming the resource usage problem than they will see denying it, so I'm not particularly worried. The list has open membership, there is no particular qualification or background required to post here. Optimal use of an information source requires critical reading and understanding the limitations of the medium. Counting comments is usually not a great way to assess technical considerations on an open public forum. Doubly so because those comments were not actually talking about the same thing I am talking about. Existing implementations are inefficient in many known ways (and, no doubt, some unknown ones). This list is about developing protocol and implementations including improving their efficiency. When talking about incentives the costs you need to consider are the costs of the best realistic option. As far as I know there is no doubt from anyone technically experienced that under the current network rules full nodes can be operated with vastly less resources than current implementations use, it's just a question of the relatively modest implementation improvements. When you argue that Bitcoin doesn't have the right incentives (and thus something??) I retort that the actual resource _requirements_ are for the protocol very low. I gave specific example numbers to enable correction or clarification if I've said something wrong or controversial. Pointing out that existing implementations are not that currently as efficient as the underlying requirements and that some large number of users do not like the efficiency of existing implementations doesn't tell me anything I disagree with or didn't already know. Whats being discussed around here contributes to prioritizing improvements over the existing implementations. I hope this clarifies something. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
Another idea: Integrate torrent download of bootstrap.dat into bitcoind. Normal user (especially a beginner) won't learn how to download bootstrap separately and import it into bitcoind; he simply give up the synchronization once he realize it takes too much time. From my experience downloading the bootstrap significantly improves catching the blockchain, which may attract some more users to run bitcoind. Not sure about C++, but simple torrent client in python is like 30 lines of code (using libtorrent). Marek On Wed, Apr 9, 2014 at 10:12 PM, slush sl...@centrum.cz wrote: I believe there're plenty bitcoind instances running, but they don't have configured port forwarding properly.There's uPNP support in bitcoind, but it works only on simple setups. Maybe there're some not yet considered way how to expose these *existing* instances to Internet, to strenghten the network. Maybe just self-test indicating the node is not reachable from outside (together with short howto like in some torrent clients). These days IPv6 is slowly deploying to server environments, but maybe there's some simple way how to bundle ipv6 tunnelling into bitcoind so any instance will become ipv6-reachable automatically? Maybe there're other ideas how to improve current situation without needs of reworking the architecture. Marek On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell gmaxw...@gmail.comwrote: On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier justusranv...@gmail.com wrote: Anyone reading the archives of the list will see about triple the number of people independently confirming the resource usage problem than they will see denying it, so I'm not particularly worried. The list has open membership, there is no particular qualification or background required to post here. Optimal use of an information source requires critical reading and understanding the limitations of the medium. Counting comments is usually not a great way to assess technical considerations on an open public forum. Doubly so because those comments were not actually talking about the same thing I am talking about. Existing implementations are inefficient in many known ways (and, no doubt, some unknown ones). This list is about developing protocol and implementations including improving their efficiency. When talking about incentives the costs you need to consider are the costs of the best realistic option. As far as I know there is no doubt from anyone technically experienced that under the current network rules full nodes can be operated with vastly less resources than current implementations use, it's just a question of the relatively modest implementation improvements. When you argue that Bitcoin doesn't have the right incentives (and thus something??) I retort that the actual resource _requirements_ are for the protocol very low. I gave specific example numbers to enable correction or clarification if I've said something wrong or controversial. Pointing out that existing implementations are not that currently as efficient as the underlying requirements and that some large number of users do not like the efficiency of existing implementations doesn't tell me anything I disagree with or didn't already know. Whats being discussed around here contributes to prioritizing improvements over the existing implementations. I hope this clarifies something. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
After some off-list discussion about details with wallet developers, it seems that structure m/cointype'/account'/change/n fulfill requirements of all wallet developers around, including myTrezor, Electrum, Multibit, Wallet32 and other software is willing to adapt once anything will be standardized (i.e. they don't care). Because I think that everybody told their comments to the topic already and because it seems that there's quite wide agreement on that, I would like to close the discussion and finally implement these paths into our software. Cheers, Marek On Fri, Mar 28, 2014 at 3:59 PM, slush sl...@centrum.cz wrote: I agree that 'version' field of bip32 is not necessary and xpriv/xpub should be enough for all cases; there's actually no need to use different BIP32 roots for different altcoins. I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by having the cointype distinction in the bip32 path itself, I'm sure that I don't reuse the same pubkey across blockchains which may be a privacy issue otherwise. Marek On Thu, Mar 27, 2014 at 5:28 PM, 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 -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille pieter.wui...@gmail.comwrote: I still don't understand the purpose of cointype. If you don't want to risk reusing the same keys across different currencies, just don't use the same seed or the same account? That is purely a client-side issue. Of course it is purely client-side issue, but it matters. There's actually no reason to generate, backup and store individual seeds for various coins and purposes. User can handle all his identities and altcoins with single seed, avoiding potential issues with using wrong seed for other purposes. Actually with accounts and cointypes in the path, you can have all your crypto funds stored on single seed, which I see as very comfortable solution. But to gain advantages of such solution and avoid reusing the same path across blockchains, we need to separate the space, which is achieved by cointype. If the consensus is to add the cointype anyway, can we fix it to be equal to the 4-byte magic in the serialization (after setting the high bit to true)? That way there aren't two 4-byte magic codes that need to be defined for each, and at the same time make it obvious from the serialized form what it is for. Serialization magic of bip32 seed is in my opinion completely unnecessary. Most of software does not care about it anyway; You can use xprv/xpub pair for main net, testnet, litecoin, dogecoin, whatevercoin. Instead using the same seed (xprv) and then separate the chains *inside* the bip32 path seems more useful to me. Marek -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
tl;dr; It is dangerous to expect that other seed than xprv does not contain bitcoins or that xprv contains only bitcoins, because technically are both situations possible. It is still safer to do the lookup; the magic itself is ambiguous. Marek On Tue, Apr 8, 2014 at 3:40 PM, slush sl...@centrum.cz wrote: Serialization magic of bip32 seed is in my opinion completely unnecessary. Most of software does not care about it anyway; You can use xprv/xpub pair for main net, testnet, litecoin, dogecoin, whatevercoin. Instead using the same seed (xprv) and then separate the chains *inside* the bip32 path seems more useful to me. Marek -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille pieter.wui...@gmail.comwrote: I see the cause of our disagreement now. You actually want to share a single BIP32 tree across different currency types, but do it in a way that guarantees that they never use the same keys. I would have expected that different chains would use independent chains, and have serializations encode which chain they belong to. Let me offer an alternative suggestion, which is compatible with the original default BIP32 structure: * You can use one seed across different chains, but the master nodes are separate. * To derive the master node from the seed, the key string Bitcoin seed is replaced by something chain-specific. I've discussed the solution of Litecoin seed in BIP32 HMAC with Litecoin devs already, and after long discussion we've concluded that it is generally bad idea. When changing Bitcoin seed constant to something different, same *entropy* will produce different *master node*. That's actually the opposite what's requested, because xprv serialization format stores *node*, not *entropy*. By changing HMAC constant, you still won't be able to store one node and derive wallets for multiple coins at same time. * Every encoded node (including master nodes) has a chain-specific serialization magic. This is in practice almost the same as your suggestion, except that the m/cointype' in m/cointype'/account'/change/n is replaced by different masters. The only disadvantage I see is that you do not have a way to encode the super master that is the parent of all chain-specific masters. You can - and with the same security properties - encode the seed, though. Actually I don't understand why there's such disagreement about cointype level here, what it breaks? I see it as the cleanest solution so far. It is forward and backward compatible, does need any special extension to bip32 (to be strict, bip32 says Bitcoin seed, so client using Litecoin seed cannot be bip32 compatible). Of course, the problem of cointype can be solved in zillion ways, but still using cointype in bip32 path seem to be the most elegant way so far, because it fullfill all requirements for single backup, for separating pubkeys and for handling all coins by one master... Marek -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach andr...@schildbach.dewrote: While there is an agreement that a standard would be useful for sharing wallets, we certainly didn't agree on every aspect of a standard. At least not on this thread, and also not at the Berlin meeting. We're going to write down BIP describing such structure. If any wallet want to be BIP XX compatible, then it has chance to. Of course if any wallet want to use another format, then it cannot call itself BIP XX compatible, thus nobody will expect that such software will see/recover all keys generated by BIP XX wallet. I understand each client will implement things a little bit different, for example the current plan is bitcoinj will hold all keys in memory and start reusing keys on low resources. Electrum uses a chain for their private purpose. Etc. It still doesn't mean that bitcoinj or Electrum cannot share the bare minimum of BIP XX. Of course if somebody will use Electrum for 2to3 transactions and then move wallet to client which does not offer such feature, it won't work. But I don't see that as a problem. If we cannot 100% agree on a standard and also agree it will not be extended in future, I think we should not even try. It's dangerous for the money of users. If some developers agree on some specific BIP, then it should be cross compatible. Of course if somebody implements BIP XX in different way, then it isn't BIP XX compatible. I propose we keep our chains deliberately separate and only try standardizing after each of us has a feel for the specific requirements. Of course, if somebody don't want to generate compatible bip32 paths, no problem. It will be the same situation as now. Marek -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address
I'm cracking my head for many months with the idea of using TREZOR for web auth purposes. Unfortunately I'm far from any usable solution yet. My main comments to your BIP: Don't use bitcoin addresses directly and don't encourage services to use this login for financial purposes. Mike is right, mixing authentication and financial services is wrong. Use some function to generate other private/public key from bitcoin's seed/private key to not leak bitcoin-related data to website. Cheers, Marek On Fri, Apr 4, 2014 at 4:42 PM, Eric Larchevêque ela...@gmail.com wrote: The goal of writing a BIP seems to be to get lots of different wallet authors to write lots of code for you - but I *am* a wallet author, and I don't think that's the right way to get traction with a new scheme. I started without a BIP and the feedback I got is that I should to a BIP. We cannot write all the code for all the wallets ; this is after all a communauty project. However we have and we will propose bounties for each wallet to support natively the protocol. For instance the TREZOR guys would have to support your new protocol otherwise if I paid my hotel bill with my TREZOR I couldn't open the door when I got there! But they probably have better things to be doing right now. Yes you are right. But if the concept of authenticating yourself gets traction, they will probably do it. The key difference between just generating a client certificate and using a Bitcoin address is that the client certificate is something that is used *specifically* for identification. It leaves no trace in the block chain, so no weird privacy issues, it doesn't matter how you manage your wallet, and you don't have to persuade lots of people to support your idea because it was already done 10 years ago and basically every browser/web server supports it. My view on this is mainly about the UX and the fact everyone in Bitcoinland has a wallet. It's a approach leveraging this fact, with the possibility to build interesting apps combining address auth and the blockchain. I understand the problems related to multisig, contracts etc, There is no such thing as a from address in a transaction, however many services still take first tx as the return address. People will always find way of building and doing stuff (cf the message in the blockchain debate). Some reasons client certs aren't more widely used boil down to: 1. People like passwords. In particular they like forgetting them and then having friendly people assist them to get it back. Client certs can support this use case, but only if apps are checking the identity in them and not the key. 2. The UI for managing client certs in browsers is pretty horrible. There's little incentive to improve it because of (1). 3. Cross-device sync doesn't work very well. Apple are starting to tackle this with their iCloud Keychain Sync service but then of course, Apple has all your keys and you may well just sign in to things with your Apple account (if it were to be supported). Cross-device sync where the server *doesn't* get your keys is supported by Chrome for passwords, but not client certs, because (1) None of the above issues have any obvious fix lurking within Bitcoin. There is also the benefit of revocation with certificate and central authority. But, again, you already have a wallet and a Bitcoin address. So if you add a simple auth protocol, people will use it at no cost. Eric -- ___ 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] Draft BIP for seamless website authentication using Bitcoin address
On Fri, Apr 4, 2014 at 5:37 PM, Mike Hearn m...@plan99.net wrote: Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins then we have a problem :) But regardless, actually like I said, you don't need a plugin. I see the plugin as a temporary solution and we'll eliminate the plugin once there'll be any way to talk to USB HID directly from browser (which is not possible yet, but there's some effort already). Marek -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
I agree that 'version' field of bip32 is not necessary and xpriv/xpub should be enough for all cases; there's actually no need to use different BIP32 roots for different altcoins. I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by having the cointype distinction in the bip32 path itself, I'm sure that I don't reuse the same pubkey across blockchains which may be a privacy issue otherwise. Marek On Thu, Mar 27, 2014 at 5:28 PM, 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
[Bitcoin-development] BIP0039: Final call
Hi all, during recent months we've reconsidered all comments which we received from the community about our BIP39 proposal and we tried to meet all requirements for such standard. Specifically the proposal now doesn't require any specific wordlist, so every client can use its very own list of preferred words. Generated mnemonic can be then applied to any other BIP39-compatible client. Please follow current draft at https://github.com/trezor/bips/blob/master/bip-0039.mediawiki. Because we're quickly moving towards release of Trezor firmware and we need to finalize this part of the firmware, we're asking for the last comments to current BIP39 draft. Thanks, slush -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039: Final call
On Mon, Jan 20, 2014 at 9:02 PM, Luke-Jr l...@dashjr.org wrote: How are they compatible if they could be using entirely different word lists?? Wordlist is necessary for the step [seed]-[mnemonic]. Step [mnemonic]-[bip32 root] doesn't need any wordlist, there's just hashing involved. For this reason client can generate whatever mnemonic and unless all clients use the same process [mnemonic]-[bip32 root], the result is the same. Maybe I'm missing something, but shouldn't this be a client-side thing, not implemented in the Trezor firmware at all?? O.o;; Trezor generates the seed and transforms it to mnemonic (which is then shown on internal display). Generating the mnemonic outside the client-side (computer) is one of main functionality of Trezor. slush -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039: Final call
On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca christophe.bio...@gmail.com wrote: I remember the wordlist choice getting bikeshedded to death a month ago. I would just include the wordlist as part of the standard (as a recommendation) so that fully compliant implementations can correct a user's typos regardless of the original generator. That's exactly our attitude. We realized that have a community-wide agreement on the wordlist itself is simply imposible, so to reach at least some consensus we split the proposal to two parts - one what is essential to call itself a bip39 compatible, i.e. converting the mnemonic to bip32 node and second which is optional, including our proposed wordlist, which has some advanced features like checksums etc. Now it is up to client developers to decide if they really insist on their superior wordlist or if they'll implement checksums following the full specification. Those who don't like it will have to deal with the compatibility concerns themselves, or get an alternate wordlist approved as a BIP. Odds are no one will go that route. At least Trezor and bitcoinj (Multibit) seems to be going in this way, which is 100% of clients which expressed interest in bip39 :-). slush On Mon, Jan 20, 2014 at 5:35 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote: On Mon, Jan 20, 2014 at 11:42 AM, slush sl...@centrum.cz wrote: Hi all, during recent months we've reconsidered all comments which we received from the community about our BIP39 proposal and we tried to meet all requirements for such standard. Specifically the proposal now doesn't require any specific wordlist, so every client can use its very own list of preferred words. Generated mnemonic can be then applied to any other BIP39-compatible client. Please follow current draft at https://github.com/trezor/bips/blob/master/bip-0039.mediawiki. So, because the [mnemonic]-[bip32 root] is just hashing, you've effectively made your mnemonic sentence into a brainwallet? Since every mnemonic sentence can now lead to a bip32 root, and only the client that created the mnemonic can verify the mnemonic passes its checksum (assuming all clients use different wordlists, the only client that can help you if you fat-finger the sentence is the client that created it)? That issue is more than enough to get a NACK from me on making the current BIP39 draft a standard - I can easily see that leading to users losing a lot of money. Have any wallets implemented BIP39 this way already in released code? -- 'peter'[:-1]@petertodd.org 9c3092c0b245722363df8b29cfbb86368f4f7303e655983a -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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
'), ('o', 'q'), ('o', 'u'), ('o', 'v'),
('p', 'q'), ('p', 'r'),
('q', 'y'),
('s', 'z'),
('u', 'v'), ('u', 'w'), ('u', 'y'),
('v', 'w'), ('v', 'y')
)
Feel free to review and comment current wordlist, but I think we're
slowly moving forward final list.
slush
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to replace BIP0039
On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin thoma...@gmx.de wrote: Indeed, I want to include a version number in the seed phrase because there are multiple ways to define the tree structure used with BIP32. It is certainly too early to make final decisions on that, or to achieve a common standard. Well, as we're the first pioneers of bip32, let's start using it in some sane way and I'm sure the others will join. Just because they don't want to incompatible software. Actually I quite like that you're not wasting bip32 space by using some dynamic allocatons in higher address space, so I'm happy to follow your rules and I think we can agree on generic discover algorithm which maybe won't be optimal, but will find all used addresses and won't need any additional information directly in mnemonic. As I wrote in previous post, in worst case I can imagine dropdown list on import dialog, which will ask user which software has been handling the seed before, to speedup the scan. But for now I don't see this necessary at all. Also, I can imagine that bip32 itself might be superseeded in the future. Although I can imagine that as well, I hope that it won't be the case. We need to unite and integrate instead of making incompatible applications. One disadvantage of bip32 is that in fact it is too much flexible, so we even falled into the necessity of defining version of discovery algorithm. Lets set up best practices how to use it and other will follow instead of creating zillion cross-incompatible algorithms which won't understand each to other. The other question we might be solving is strenghtening (your proposal). I consider that this is not a strong requirement for Electrum, because it does not let the user choose their seed phrase. However, if a few bits of the seed phrase are Hardening and password protection are two unrelated requirements. Again, there are some scenarios in which use can leak part of the mnemonic to attacker, so hardening prevent to bruteforce the rest information by attacker, even if the mnemonic isn't passphrase protected. I'm especially refering to our algorithm of mnemonic import to Trezor during disaster recovery (when Trezor is destroyed and user wants to import the seed to another one), so that leak isn't just a theoretical concept, but real-word scenario. allocated for metadata, then I guess strenghtening can be part of it. That's another good reason to have a version number encapsulated in the seed. Actually creating optional features of such algorithm only make things complicated (and less cross-compatible). Every software still needs to implement such hardening even if it is optional feature, to be compatible with other clients. Then I don't see any reason why to have it optional. Don't forget that the proposal uses only 4 bits of version, which isn't too much combination for all these optional features ;-). I too wonder why the transformation needs to be bidirectional in bip39. Well, I wrote longer answer in previous email. tl;dr; there's quite easy way how to make the algorithm bi-directional, so I don't see a necessity to drop potentially useful feature for no good reason. I was thinking about your proposal and I realized that both our solutions solves a bit different problem. Lets summarize features (and forget to wordlist fights for moment): bip39: + bi-directional + passphrase protected + shorter mnemonic or shorter wordlist - predefined wordlist ThomasV proposal: + any software can has its own preferred worlist ? passphrase protected - one-direction only - longer mnemonic or longer wordlist Back to wordlist fights a) actually I think that the wordlist choice is far less important than it may look at first glance. Thomas thinks that bip39 wordlist is disaster, me and many other thinks it is ok, but mainly that it is very subjective. b) I see the beauty of custom wordlists in Thomas proposal, still if it means the algorithm is uni-direction only, it is very strong disadvantage to our usecase. c) I advocated our wordlist mainly because we put a lot of effort into it and after many weeks of tuning it is already done; not because I think that one method of picking the words is superior to other. I mean - if Thomas can offer any other plain-english wordlist which he'll be happy with, I'll vote for dropping our own wordlist and to use Thomas's version for the deal that he'll accept our need for bi-directionality and he agrees on the rest of bip39 ;-). Marek -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list
Re: [Bitcoin-development] Proposal to replace BIP0039
Oh, I forgot to one practical aspect; the way how the mnemonic is mined in Thomas proposal prevents usage in embedded devices, because difficulty of generating proper mnemonic is simply too high for embedded microcontrollers. Maybe this can be solved somehow by modifying the proposal, but right now it is a showstopper for us. Marek On Thu, Oct 31, 2013 at 12:11 PM, slush sl...@centrum.cz wrote: bip39: + bi-directional + passphrase protected + shorter mnemonic or shorter wordlist - predefined wordlist ThomasV proposal: + any software can has its own preferred worlist ? passphrase protected - one-direction only - longer mnemonic or longer wordlist -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/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
Hi Thomas, can you more elaborate on that version bits? What is exact meaning of it? I still think this is more an implementation problem. What stops Electrum to do the same algorithm for searching branches as it is now for used addresses? These version bits need to be covered by the specification as well, because if any client will use them differently (or won't use them at all), it will break cross-compatibility between clients, which was another goal of bip39. Marek On Sat, Oct 26, 2013 at 5:24 PM, Thomas Voegtlin thoma...@gmx.de wrote: here is a simple implementation, with some ideas on how to format the metadata: https://en.bitcoin.it/wiki/Talk:BIP_0039 -- 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=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=60135991iu=/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
I've just pushed updated wordlist which is filtered to similar characters
taken from this matrix.
BIP39 now consider following character pairs as similar:
similar = (
('a', 'c'), ('a', 'e'), ('a', 'o'),
('b', 'd'), ('b', 'h'), ('b', 'p'), ('b', 'q'), ('b', 'r'),
('c', 'e'), ('c', 'g'), ('c', 'n'), ('c', 'o'), ('c', 'q'),
('c', 'u'),
('d', 'g'), ('d', 'h'), ('d', 'o'), ('d', 'p'), ('d', 'q'),
('e', 'f'), ('e', 'o'),
('f', 'i'), ('f', 'j'), ('f', 'l'), ('f', 'p'), ('f', 't'),
('g', 'j'), ('g', 'o'), ('g', 'p'), ('g', 'q'), ('g', 'y'),
('h', 'k'), ('h', 'l'), ('h', 'm'), ('h', 'n'), ('h', 'r'),
('i', 'j'), ('i', 'l'), ('i', 't'), ('i', 'y'),
('j', 'l'), ('j', 'p'), ('j', 'q'), ('j', 'y'),
('k', 'x'),
('l', 't'),
('m', 'n'), ('m', 'w'),
('n', 'u'), ('n', 'z'),
('o', 'p'), ('o', 'q'), ('o', 'u'), ('o', 'v'),
('p', 'q'), ('p', 'r'),
('q', 'y'),
('s', 'z'),
('u', 'v'), ('u', 'w'), ('u', 'y'),
('v', 'w'), ('v', 'y')
)
Feel free to review and comment current wordlist, but I think we're slowly
moving forward final list.
slush
On Sat, Oct 19, 2013 at 1:58 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
some fairly old wordlist solver code of mine:
https://people.xiph.org/~greg/wordlist.visual.py
it has a 52x52 letter visual similarity matrix in it (along with a
citation)
On Fri, Oct 18, 2013 at 4:52 PM, jan jan.mare...@gmail.com wrote:
The words 'public', 'private' and 'secret' could be confusing when
encoding public and private keys. eg. a private key that begins with
the word 'public'.
I think avoiding words that could look similar when written down would
be a good idea aswell. I searched for words that only differ by the
letters c e, g y, u v and found the following:
car ear
cat eat
gear year
value valve
Other combinations could potentially be problematic depending on the
handwriting style: ft, ao, ij, vy, possibly even lt and il?
I've included the search utility I used below.
#include stdbool.h
#include string.h
#include stdio.h
char *similar_char_pairs[] = { ce, gy, uv, NULL };
bool is_similar_char(char c1, char c2)
{
char **pairs = similar_char_pairs;
do {
char *p = *pairs;
if ((c1 == p[0] c2 == p[1]) ||
(c1 == p[1] c2 == p[0]))
return true;
} while (*++pairs);
return false;
}
bool print_words_if_similar(char *word1, char *word2)
{
/* reject words of different lengths */
if (strlen(word1) != strlen(word2))
return false;
size_t i, similarcount = 0;
for (i = 0; i strlen(word1); i++) {
/* skip identical letters */
if (word1[i] == word2[i])
continue;
/* reject words that don't match */
if (is_similar_char(word1[i], word2[i]) == false)
return false;
similarcount++;
}
/* reject words with more than 1 different letter */
//if (similarcount 1)
// return false;
printf(%s %s\n, word1, word2);
return true;
}
int main(void)
{
/* english.txt is assumed to exist in the working directory
download from:
https://github.com/trezor/python-mnemonic/blob/master/mnemonic/wordlist/english.txt*/
FILE* f = fopen(english.txt, r);
if (!f) {
fprintf(stderr, failed to open english.txt\n);
return 1;
}
/* read in word list, assumes one word per line */
#define MAXWORD 16
char wordlist[2048][MAXWORD];
int word = 0;
while (fgets(wordlist[word], MAXWORD, f)) {
/* strip trailing whitespace, assumes no leading whitespace */
char *ch = strpbrk(wordlist[word], \n\t);
if (ch)
*ch = '\0';
word++;
}
if (word != 2048) {
fprintf(stderr, word list incorrect length\n);
return 1;
}
/* check each word for similarity against every other word */
int i, j, count = 0;
for (i = 0; i 2048; i++) {
for (j = i+1; j 2048; j++) {
if (print_words_if_similar(wordlist[i], wordlist[j]))
count++;
}
}
printf(%d matches\n, count);
return 0;
}
--
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] Proposal to replace BIP0039
On Thu, Oct 24, 2013 at 7:29 PM, thoma...@gmx.de wrote: My initial problem was that BIP0039 is not backward compatible with Electrum. When trying to solve that, I realized that the seed encoding used in Electrum does not help, because it does not contain a version number information. However, BIP0039 suffers the same shortcoming: it does nothing to help a future replacement, it wants to be final. My first recommendation is to allocate a few bits of the mnemonic, in order to encode a version number along with the checksum bits. Two years ago I proposed exactly this and you refused to add extra information to mnemonic, because it isn't necessary and it makes it longer to mnemonization. What changed since then? The second problem is the wallet structure. There are multiple ways to use a BIP32 tree, and each client will certainly handle this differently. For Electrum, it is important to be able to recover an entire wallet from its mnemonic, using no extra information. Thus, the client needs to know which branches of the BIP32 tree are populated by default. This means that the version number I mentioned will not only be about the seed encoding, but it should also give some information about the wallet structure, at least in the case of Electrum. Hm, what exactly do you need to store about wallet structure? I lived in opinion that everything is able to recover using CKD function to generate new addresses and blockchain lookups for their balances. The third problem is the dictionary. I do not like the dictionary proposed in BIP0039, because it contains too many short words, which are bad for memorization (I explained here how I designed the dictionary used by Electrum: https://bitcointalk.org/index.php?topic=153990.msg2167909#msg2167909). I had some discussions with slush about this, but I do not think it will ever be possible to find a consensus on that topic. Yes, that's true. It isn't possible to make everybody 100% happy. At least I wanted to be constructive and asked you to replace the most problematic words. No pull request from you so far. BIP0039 also suggests to use localized dictionaries, with non-colliding word lists, but it is not clear how that will be achieved; it seems to be difficult, because languages often have words in common. It looks like a first-come-first-served aproach will be used. Yes, it was original idea. So far I don't think this is a problem. Of course some words may have some meaning across languages, but it should be easy to avoid them. There are tens of thousands words in every language and we need to pick only 2048 words to wordlist. For these reasons, I believe that we need a dictionary-independent solution. This will allow developers to use the dictionary they like, and localization will be easy. I would like to suggest the following solution: If I understand this well, it is basically one-way algorithm mnemonic - seed, right? Seed cannot be printed out as mnemonic, because there's hashing involved, but the bi-directionality has been the original requirement for such algorithm (at least in Electrum and bip39). Then, how is this different to picking 12 random words from dictionary and hashing them together? I don't see any benefit in that mining part of the proposal (except that it is lowering the entropy for given length of mnemonic). This solution makes it possible for developers to define new dictionaries, localized or adapted to a particular need. Are your worries about overlapping words across languages a real issue? slush -- 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=60135991iu=/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
We've reflected many comments about BIP39 wordlist from the community and I think the wordlist is much better now. Specifically we removed many of theoretically offensive words as well as we implemented algorithm for detecting words with similar characters (cat/eat) and we resolved these duplicities. I'm now quite happy with the wordlist and I want to ask you for next (final?) round of comments. From other features, we added password protection of seed and seed hardening (against bruteforcing) using Rijndael cipher. This has been chosen because its blocksize can be 128, 192 or 256 bits, so it fits length of desired seeds. Also there are Rijndael implementations in every language. Btw password protection has one interesting feature - plausible deniability. It allows user to have one mnemonic and by using it with different passwords, it will generate different BIP32 wallets (wink wink) I want to be pretty clear that we need to close this topic somehow, because we want to use such algorithm in Trezor (which deadline is coming quick) and also other wallet developers want to implement such algorithm into clients to be compatible with Trezor. There were quite strict requirements for such algorithm (like the possibility to convert mnemonic to seed as well as seed to mnemonic) and I think we found a good solution. I'm wildly asking you for constructive comments, but saying it's a crap, I don't like it won't help anything. Thanks, slush On Thu, Sep 12, 2013 at 6:02 PM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: I removed some more but I haven't added enough back in. It was taking far longer than expected so I gave up, but maybe someone else can try to add some more: https://github.com/MatthewLM/python-mnemonic/blob/master/mnemonic/wordlist/english.txt On 12 Sep 2013, at 13:11, Pavol Rusnak st...@gk2.sk wrote: On 10/09/13 23:03, Matthew Mitchell wrote: Maybe it would have been better without the aggressive words? I revisited the wordlist and replaced around 67 words that can be found offensive in some context. -- 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 -- 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 -- 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=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys
On Thu, Oct 24, 2013 at 9:23 PM, Pieter Wuille pieter.wui...@gmail.comwrote: This is a proposal I wrote a year ago, but never spent enough work to push it as a standard: https://bitcointalk.org/index.php?topic=102349.0 I think that PoW concept in your proposal is quite smart! However the problem that it isn't bidirectional; it don't allow to convert back and forth between mnemonic and seed, which was one of basic requirement for such algorithm. slush -- 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=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys
On Thu, Oct 24, 2013 at 9:32 PM, Jorge Timón jti...@monetize.io wrote: This will probably sound stupid to most of you, but I'll say it anyway. The aim of mnemonics is to easily remember, isn't it? Well, I would say more retype than remember. I really don't think that common user will memorize it. But of course, it is still an option. But the approach of removing offensive words is probably counterproductive to achieving that end. These words cause a greater emotional impact in our human moral psyches. No, I dont' think it is stupid! Actually it was my concern as well. Unfortunately I don't think it is politically correct to include all bitches, assholes and motherfuckers in end user product :-). If we were willing to use that fact in our advantage to optimize the maximum unforgettableness criterion, we should actually prefer the most generally offensive words in that list. Specially if they can combine with each other to produce more offensive results, basically the opposite of what we're doing. Isn't legalize murder dirty jew much easier to remember for most people than sandwich house yellow cauliflower? Well, bip39 can have more dictionaries and *maybe* swearword dictionary would gain some popularity ;). slush -- 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=60135991iu=/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
I think this is a good idea; I just pushed new unit test test_similarity() to github which finds such similar words. Right now it identifies ~90 similar pairs in current wordlist, I'll update wordlist tomorrow to pass this test. slush On Sat, Oct 19, 2013 at 1:52 AM, jan jan.mare...@gmail.com wrote: I think avoiding words that could look similar when written down would be a good idea aswell. I searched for words that only differ by the letters c e, g y, u v and found the following: car ear cat eat gear year value valve Other combinations could potentially be problematic depending on the handwriting style: ft, ao, ij, vy, possibly even lt and il? -- 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=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoind stops responding
ad RPC stops working: * Client makes a 'getinfo' call and don't receive a response in a minute. What is your precise RPC usage? One process is asking getinfo every second as a fallback to possibly misconfigured blocknotify. It also calls getblocktemplate every 30 second. Second process is calling getinfo once a minute to check if bitcoind is working. If it don't receive a response in a minute, it kills bitcoind and starts it again. That's all. OS is Debian. On Tue, Oct 1, 2013 at 3:17 AM, Jeff Garzik jgar...@bitpay.com wrote: Can you please describe more than RPC stops working? What is your precise RPC usage? getwork? getblocktemplate? other calls? What is your OS? -- 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=60134791iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Python implementation of RFC 6979
Hi all, yesterday I found some time and implemented RFC 6979 into python-ecdsa module. RFC 6979 proposes algorithm of calculating 'k' value for signature from private key and signed data, so the 'k' is unique, but deterministic for every signature. This enabled simple unit tests of code using ECDSA signatures as well as some nice use cases for blackbox testing of 3rd party software (you can calculate on your own if some software is making valid signature, because there's no randomnes involved in the process). Yes, I'm referring Trezor :-). There's my fork of python-ecdsa with RFC 6979: https://github.com/trezor/python-ecdsa/ There's pull request waiting for python-ecdsa author aproval: https://github.com/warner/python-ecdsa/pull/10 Aaand there's RFC 6979: tools.ietf.org/html/rfc6979 Thanks, slush -- 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
Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys
In many iterations of editing the wordlist we made our best to pick words which are easy to remember, still neutral. Unfortunately it's almost impossible to exclude some words which may together create negative co-notations. Thankfully we removed all racist and religious words so I believe all three authors mentioned in the BIP are safe against fundamentalist bitcoin users :-). slush On 9/10/13, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: I like this, though maybe sometimes you'll get rude word combinations come out. Matthew -- 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
Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys
We're open to changes in the wordlist. We'll accept pull request replacing potentially offensive words by another more neutral, which also fits all other requirements. Putting the wordlist together is really hard job and we spent few sleepless nights on that. By the way, words murder, black, people are contained also in Electrum wordlist and nobody complained yet :-). slush On 9/11/13, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Sep 10, 2013 at 2:03 PM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: Well let's hope something like murder black people, stupid asian person or whip african slave doesn't come up. :-) Maybe it would have been better without the aggressive words? Ouch. This sounds like something that $20 of mechanical turk time could help out with a lot. Put up the 2048 words and ask people to rate them for potential offensiveness and threatening. :) Nouns often make for fairly neutral words, though careful for place names which have had political complications. E.g. gdansk vs danzig. -- 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
Re: [Bitcoin-development] Version 0.9 goals
Pieter, Matt and I also agreed that for maximum impact we should really try to ship payment protocol support in at least two clients simultaneously and ideally with a big merchant signed up too - to send a powerful message that we really mean it. Someone volunteered last week to do it for bitcoinj and if he doesn't pull through, I have some old code from EOY 2012 that I could update to the latest spec and ship at least some basic support. I'd hope that we can get Bitcoin Wallet or MultiBit updates out once bcj has support pretty fast. We're planning to support payment protocol in Trezor as well, if it counts. I think it's a missing piece in absolute security of hardware wallets. slush -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.9 goals
On Thu, Aug 15, 2013 at 11:02 AM, Mike Hearn m...@plan99.net wrote: On Thu, Aug 15, 2013 at 10:22 AM, slush sl...@centrum.cz wrote: We're planning to support payment protocol in Trezor as well, if it counts. I think it's a missing piece in absolute security of hardware wallets. Yup, that's always been the plan :-) Any idea how much work it is, and would it be a v1 feature of the Trezor or added later via firmware update? Our plan is to add support for that into v1 firmware, but it also depends on readiness of surrounding infrastructure; mainly if there'll be support for payment protocol in multibit in the time of v1 release (I suppose that the Multibit will be the first wallet compatible with Trezor AND supporting payment protocol). slush -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
Agree. I quite like Mark's proposal. Yes, formally it is hard fork. But the step 4) can come very far in the future, when the penetration of 0.8 clients will be mininimal. slush On Wed, Mar 13, 2013 at 7:27 PM, Mark Friedenbach m...@monetize.io wrote: This problem is very clearly a *bug* in the old codebase. So let's be forward thinking and do what we would do in any other situation: fix the bug, responsibly notify people and give them time to react, then move on. Let's not codify the bug in the protocol. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Jim, perfect idea with some logo indicating wallet compatibility! This should cover BIP32 + some mnemonic algorithm for easy transferring of wallets across various clients. Btw I asked ThomasV for making BIP from his mnemonic algorithm and he agreed, so I believe some proposal will be here pretty soon. slush On Tue, Dec 4, 2012 at 7:56 PM, Jim jim...@fastmail.co.uk wrote: Also, as BIP32 support is added to clients and codebases then the actual variant of software to use to access your wallet will become relatively less important. Combined with a standardised seed - passphrase algorithm the user can just type in their long passphrase into any BIP32 compliant software and click/ buzz/ whirr : there is their wallet. We should have a little logo for HD wallet compliance ! :-) -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Hi, not sure if you already noticed, but I and my friends are actively working on bitcoin hardware wallet. This should be pocket size device with something like 256kB flash and 80 MHz CPU, talking with the computer over USB. User will prepare transaction on the machine, send it to the device, device shows target address on the display and user confirms it by pressing the button. We're trying to make bitcoin payments safe even on hacked computer. For this reason we're also implementing SPV so device don't need to trust computer with any kind of information. The biggest existing problem is that user cannot be sure that the address displayed on computer screen is correct and he's confirming valid address. I don't have any solution for this problem yet. I just appreciate an activity in payment protocol area, because it can (with some care) solve this problem and my appeal si to keep all this simple. I'd be very happy with simple payment protocol which can be implemented even on devices like I'm working on, so device with few widely used certificates stored in the memory will be able to display origin of the invoice and confirm its validity. slush On Thu, Nov 29, 2012 at 1:30 AM, Watson Ladd w...@uchicago.edu wrote: After doing more thinking, what about letting a spend sign more information associated with the transaction, such as a transaction ID provided by the merchant? This seems to solve a lot of the problems being put forward, with much less complexity. -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday
On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr l...@dashjr.org wrote: But more important to the success of BIP today, I think, is encouraging wider community participation. It's not about BIP process, it's possibly about content of particular proposals. The stratum mining mess seems to be a direct result There's no mess with stratum mining, except in your head. There's no requirement to have BIP for everything what people do. Stratum is NOT related to bitcoin protocol or bitcoin implementation, it is just custom, pooled-mining extension and bitcoin network doesn't need to know about Stratum existence at all. and lack of any peer review/contribution toward the stratum protocol. There have been peer review of the protocol. You wanted to say I was not invited to do peer review, right? Please don't start it AGAIN and stop bashing Stratum in your posts, at least in bitcoin-dev mailing list. I promised to write BIP draft for Stratum, I proposed and implemented get_transactions method to allow Stratum jobs inspection. What more do you want, seriously? I'm soo tired by you, Luke. slush P.S. I'm sorry that other developers had to read such posts. I'll try to sit on my hands next time. -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] IRC meeting Tuesday, Feb 14, 21:00 UTC
Hello Gavin, excuse me, but do you think it's good idea to have IRC meeting on Valentine's evening? Some of us have girlfriends :-). slush On Tue, Feb 14, 2012 at 3:49 AM, Gavin Andresen gavinandre...@gmail.comwrote: Tomorrow, Feb 14'th at 21:00 UTC on #bitcoin-dev on Freenode IRC I'd like to chat about: Status of BIP 16 support (progress towards 50% hashing power). Protocol change coming up Feb. 20 (checksums in version messages). Duplicate coinbase issue (and requiring block height in the coinbase as a solution). Then when we're done talking tech we can all send each other bitcoins with addresses that are cute Valentine's day messages... -- -- Gavin Andresen -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout
I agree Bitcoin should avoid making any bold political stands. I agree on this. Please don't turn Bitcoin project/homepage into some political agitation. Not everybody care about political attitude of main project developers. slush On Tue, Jan 17, 2012 at 1:46 AM, Alan Reiner etothe...@gmail.com wrote: ** You guys are representing both extremes of the issue. In response to Jeff and Luke-Jr, I don't see how this is *just any other poltical issue*. It strikes at the heart of everything Bitcoin is about. Barring Bitcoin-specific legislation, I don't see how any legislation could be more relevant to Bitcoin and the community around it. On the other hand, Bitcoin is still a non-entity, and shouldn't get in the business of making statements. A central voice for Bitcoin gives the impression that it is actually centralized, and one that has opinions. Plus I wouldn't be surprised if some, heavily-invested Bitcoin users were of the opinion that SOPA/PIPA/whatever could be a huge profit for themselves: once SOPA kicks in and businesses around the world start getting cut off for legit or illegitimate purposes, a lot of them could potentially switch to Bitcoin to keep their business going. That could be a huge boon for Bitcoin. You may not agree it's worth the tradeoff, but people are selfish and may not actually understand or even care about SOPA legislation itself. I think it's *not inappropriate* for something to be mentioned on the website about Bitcoin's philosophy being threatened by SOPA, but I agree Bitcoin should avoid making any bold political stands. Users could be reminded that SOPA affects yet another thing they care about, but it might be better to avoid it altogether. If any response is made, it should be a very light one. -Alan On 01/16/2012 07:30 PM, Amir Taaki wrote: Bunk argument. This is an issue that affects bitcoin directly. Wikipedia has far more need to remain neutral and apolitical than bitcoin ever does- you've read Satoshi's politically charged whitepaper or seen the genesis block quote. http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action The Wikipedia community decided on a full and global blackout. Bitcoin should do the same in unison with the rest of the web- sites like Reddit, 4chan and Wikipedia. It's funny / almost comical how you consign this to being just another issue or case of moral alarm. Sad. - Original Message - From: Jeff Garzik jgar...@exmulti.com jgar...@exmulti.com To: Amir Taaki zgen...@yahoo.com zgen...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Sunday, January 15, 2012 10:37 PM Subject: Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki zgen...@yahoo.com zgen...@yahoo.com wrote: How is this not the most important world issue right now? EVERYTHING is under threat. Go nuclear to show our nerd-rage. Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy. There are always issues that raise ire and moral outrage. I would rather that bitcoin.org stay apolitical -- our users will appreciate this in the long run. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
Pieter, it was more rhetorical question than asking for explanation, but thanks anyway. As an Internet application developer, I of course understand security issues while using HTTPS and CA. I have a gut feeling that there simply does not exist any single solution which is both easy to use and secure enough. At least nobody mentioned it yet. And if I need to choose between easy solution or secure solution for aliases, I'll pick that easy one. I mean - we need some solution which will be easy enough for daily use; it is something what we currently don't have. But if I want to be really really sure I'm using correct destination for paying $1mil for a house, I can every time ask for real bitcoin addresses, this is that secure way which we currently have. slush On Mon, Dec 19, 2011 at 2:14 AM, Pieter Wuille pieter.wui...@gmail.comwrote: On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote: Maybe I'm retarded, but where's the point in providing alliases containing yet another hash in URL? Any DNS-based alias system is vulnerable to spoofing. If I can make people's DNS server believe that mining.cz points to my IP, I'll receive payments to you... If no trusted CA is used to authenticate the communication, there is no way to be sure the one you are asking how to pay, is the person you want to pay. Therefore, one solution is to put a bitcoin address in the identification string itself, and requiring SSL communication authenticated using the respective key. This makes the identification strings obviously less useful as aliases, but pure aliases in the sense of human-typable strings have imho limited usefulness anyway - in most cases these identification strings will be communicated through other electronic means anyway. Furthermore, the embedded bitcoin address could be hidden from the user: retrieved when first connecting, and stored together with the URI in an address book. Like ssh, it could warn the user if the key changes (which wil be ignored by most users anyway, but what do you do about that?) -- Pieter -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
I really like this proposal with standard URLs. All other proposals like DNS mapping or email aliases converted to URLs with some weird logic looks strange to me. Plain URLs (returning address in response body, redirecting to URI bitcoin:address or anything else) are very clear solution, easy to implement in clients and very easy to understand by people. It's also extremely flexible - almost everybody can somewhere setup static file containing his personal addresses or it's very easy to integrate such solution with eshops (providing custom address for given order) etc. I'm definitely for this solution. Best, slush On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins andypark...@gmail.com wrote: On 2011 December 13 Tuesday, Amir Taaki wrote: Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal. I don't like the idea of a hard-coded mapping at all. We shouldn't be making choices on behalf of server operators. It's up to them how they arrange their domain names and paths. I also agree that DNS is not the technology to use. DNS is a nightmare. gen...@foo.org Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system responds with a bitcoin address. Whether the system gives you a new address from a pool of addresses, or contacts the merchant behind the scenes is implementation defined. I'll clarify it later. This is the relevant line: string strRequestUrl = strDomain + /bitcoin-alias/?handle= + pszEncodedNick; Between HTTPS service and server service, I lean slightly towards HTTPS (automatic encrypted connection, CAs + all benefits of DNS). But still interested in arguments in favour of a server service (daemon answering queries). Why bother with an encoding scheme at all? If the address gen...@foo.org always maps to https://foo.org/bitcoin-alias/?handle=genjix Then forget the hardcoding of https the hardcoding of bitcoin-alias and ?handle= and the original email-looking gen...@foo.org. Just use the URL. Then the author of the service can use whatever they want. Can I pay you 10 BTC? Sure, send it to 'https://bitcoinalias.foo.org/genjix/' While I might implement my alias server like this: Sure, send it to 'https://google.com/bitcoin/?andyparkins' Sure, send it to 'https://parkins.co.uk/; ... or any other URL they want -- any of which suit might suit me and my webserver better than whatever mapping would otherwise be hard-coded. The world is already very familiar with URLs so this is no more scary than the email address. What's more, the email address form looks _too much_ like an email address, and will only lead to confusion ... send it to gen...@foo.org so I use outlook express for that, right? erm, no, you put it in your bitcoin client. The URL form could easily be made to detect a browser connecting rather than a bitcoin client (and this is an area that would benefit from a standards document -- define the headers and user agent triggers that an alias server expects) and give them better instructions. https can be specified as the default, so https://; can be optional when they're typing. If, in the future, bitcoin gets a distributed peer-to-peer alias system, then a new URL type can be added easily bcalias://andyparkins might automatically find my node in the network and query it for an address (or whatever). All of the above is exactly why OpenID chose to use URLs for ID. Andy -- Dr Andy Parkins andypark...@gmail.com -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
